On Feb 10, 2008, at 11:40 AM, 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?

They might do other things besides that, but I am no expert.   _All_  
that I want is the agglomeration.

>
> 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!

I agree about the interfaces being visible, but _not_ the _arbitrary_  
names that I have chosen simply to make them unique.   Methods "add 
()", "print()", etc are good names.   Overloading them is good  
(TM).   Having to also expose addInteger(), addReal(), addComplex 
() ... is unnecessary from the clients point of view.   I'm sure I'll  
get used to it, but my Java colleagues will continue to taunt me.  :-)

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

That would be a way around this, but it seems overkill since the only  
real problem here is the pollution of the namespace.  In C++ I would  
not need "friend" in this example.   My methods would all be public  
(deferred/virtual or otherwise), but share a common generic name.   
I'm really not doing anything nearly as profound as some of the  
comments in this thread have implied.

>
> Also note that Fortran 2008 will have submodules, which can help  
> break up large modules.

F2009, last I heard.   And my current project certainly cannot wait  
for widespread implementation of that standard. :-)

Cheers,

- Tom

>
> Aleks

Cheers,

- Tom