Hi Tom,

Hi Malcolm,

> If F90 style modules, this was ok, as one would make the  
> generic name public and the other names private.   All such  
> procedures were externally accessible through the generic name, while  
> the private ones were not.    Now, with OO, there seems to be a
major  
> problem with this approach.

Actually, I don't think the OO stuff makes it any different.
If there are private/public problems in one way, there is in
the other.

>   I want to have a set of deferred type- 
> bound procedures that use the same method name (i.e. generic). 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).    If I make them  
> private, then I'm fearing that the subclasses will not be able to be  
> declared.  Again, with traditional OO this does not arise, since only  
> the generic name exists in the first place.

Well, you say "traditional OO", but the older OO systems varied
quite a lot on what was and was not possible here.  "Generics"
were not in a lot of systems, and in any case the concept of genericity is, I think, orthogonal to the OO paradigm.

One thing about Fortran generics is that you only add to the
generic set, you never take anything away.  That's true whether
you are using Fortran 90 INTERFACE blocks or F2003 OO.

There are also reliability and correctness issues which underlie
some of the decisions made both in the F90 and the F2003 approaches.
As usual, the disadvantage of making it harder to shoot oneself in
the foot has a side-effect of making it less flexible to use.

Anyway, having a private type-bound procedure doesn't stop
subclasses from being created, but it does stop them from overriding
the tbp.  That's not the *purpose* of "private", just a consequence.

Yes, for generic tbps that is a bit of a restriction.  The big plus
point is that it is very easy to tell what is happening, both for the
compiler and the human reader: GENERIC always adds things to the
generic, PROCEDURE always overrides (unless there wasn't anything
being inherited).  It is also easy to describe, explain and
implement.

The minus point is that it means that if you want to allow overriding of some specific (in a generic), you have to make it public.  I
agree that is a bit of a limitation, and it puts the burden on you
to manage the names intelligently.

> One of the main advantages I want from OO is the  
> ability to provide a set of base classes which other members of the  
> community extend for their purposes.   If they all have to put their  
> extensions in my base module, things are, lets just say unpleasant.

As explained above, they don't have to do that.

BTW, in earlier drafts of F2003 we tried to get the compiler to
automatically manage this stuff but it ended up WAY too complicated.
And suffered from the "accidental override" syndrome (where someone
intended to extend the generic but overrode it instead, potentially
breaking its behaviour in very unexpected ways).  Having to give a
tutorial every other meeting on how this was supposed to all work
was bad enough, but getting it understood by the users was even
harder!  Not to mention getting the definitions in the standard right.

So we changed it to the current, much simpler, system.  Easier to
understand the ideas, easier to understand the resulting programs,
easier to implement (let's not underestimate *that* one).  But if
you want to let someone override a specific in a generic, you have
to give them a name so they can specify the override.

BTW, we did extend the maximum length of names to 63 characters, so
that makes it easier to come up with a reasonably coherent naming
system for the specifics you want to allow overriding for.

Of course in the future we could add some syntax that provided
overriding of a private specific, e.g.
  GENERIC,OVERRIDE :: generic => new_specific
Actually, that's probably a good idea for the future.
What do you think?

> Two workarounds are obvious.  (a) Don't use generic names or (b)  
> expose the private names.      I'm guessing that I will opt for the  
> latter.

That is, I think, the right solution in F2003.  Choice (a) doesn't
make sense to me - it's going to be the same as (b) for the user
writing a type extension, and less convenient for the user who just
wants to use someone else's type.

I understand your point about how some other systems handle genericity,
but there are advantages as well as disadvantages to the F90
approach.  And we wanted to have type-bound generics work basically
the same way as the existing generics; having different rules here
would have been really bad IMNSHO.

Cheers,
-- 
......................Malcolm.