 |
 |
Aleksandar Donev wrote: > Hi again, > >> In typical OO languages this is done by using the same name for each >> method, but requiring a different signature. Fortran >> for-better-or-worse requires a unique procedure name for each signature. > In Fortran a generic interface is nothing more than an agglomeration > of specific interfaces, which do not overlap in their applicability, > and are dispatched at compile time based on the call signature. > Unfortunately, in Fortran generic dispatch is not based on a > "preference" scheme, that is, a scheme where one chooses the interface > that best matches out of possibly several options. This has been > proposed but it is a lot of work (for the standard and compilers) and > has been rejected. What do these other languages (i.e., C++) do exactly? > > Given this, you CAN indeed specify a new binding in your extended type > with the name RealInterface and bind it to a specific procedure. BUT, > this will not override the original TBP since that name no longer > refers to the original TBP, as the name is no longer accessible via > host association. As Van said, you will create a new TBP. When you try > to add that name to the generic interface, I suspect the compiler will > complain about conflicting with the original RealInterface (assuming > the compiler doesn't give the spurious error message it did). But this > is because of the way generics work in Fortran and is not specifically > tied to TBPs (although the interaction may be an unforseen and > unfortunate interaction). I don't think the compiler ought to complain about generic resolution problems unless the bindings have NOPASS. If they don't have NOPASS, they have to have an argument of the type to which they're bound, so generic resolution ought to work -- regardless of whether the bindings in the base type are deferred or not, private or not. > > If I make the >> specific-names public, then the clients will have access to the >> private names which is poor style (otherwise why did we bother >> making them private in the F90 style). > It is not really that poor style. You want to hide the private names > from clients that don't need to know anything about the internals of > the types. But clients that actually muck around with the type > hierarchy DO need to know about what bindings are there and what the > signatures are etc., so making them private is pointless---it hides a > name that you need to know is there! C++ has some complex "friend" > tool in namespace management but we only have private and public, > sorry. And even those are not meant to give you 100% security---they > are merely tools for namespace management. > Also note that Fortran 2008 will have submodules, which can help break > up large modules. We also need the equivalent of Ada's public child unit, which would be an extension of a module that would have access to the private entities of a module. Module extensions would be accessible by use association, while submodules are not. This was debated and rejected. It's much better to encapsulate access to private entities in a scoping unit identified as a module extension than it is to make the entities public. The Ada community reached this conclusion in 1995. Problems of this kind illustrate why I proposed the facility at the time submodules were under development. Ada does not distinguish between public entities available by "with" (their spelling for Fortran's USE) and private entities available by child unit extension. C++ does with its complicated and subtle distinction between private, protected and public. Fortran could someday provide a similar distinction by allowing private entities to be accessible in module extensions (where they would still be private, and therefore not accessible by use association from the module extension), and providing a new attribute, say INVISIBLE that specifies an entity is neither accessible by use association, nor by extension. -- Van Snyder