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).
> 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.
Aleks
|