Hi Malcolm,

Thank you for such a thorough response.   I
On Feb 11, 2008, at 9:25 AM, Malcolm Cohen wrote:

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

The difference arises in OO because of the desire to override.   Does  
not happen in F90.   Clients never need the specific names in F90.   
Subclasses do need the specific names in F2003.

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

I'll take your word for it.

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

Agreed.

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

I like it providing the intent is that "old_specific" could have been  
private and in a different module?   Alternatively a new attribute  
which exposes procedures/components to subclasses but not to  
clients.   I think "protected" is used in some languages for this,  
but I'm certainly not fluent in any specific OO language.

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

Agreed.

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

Understood.   I'm getting used to the compromise now.   In the grand  
scheme of things it will be a small one compared to some other things  
I'd like to do.

Cheers,

- Tom

Thomas Clune, Ph.D.							301-286-4635 (W)
Advanced Software Technology Group			240-266-0400 (F)
Software Integration and Visualization Office	<[log in to unmask]>
NASA GSFC (610.3)                              			 <http:// 
sivo.gsfc.nasa.gov>