(j3.2006) Abstract types, deferred bindings, generic bindings

[Rafik Zurob]

I shouldn't send email on Friday nights (or maybe at all ;-)).  The Interp 
I quoted actually goes with "not allowed" as opposed to "allowed".  I've 
gone back and read my notes on the F2003 generic bindings feature.  We 
initially also read the standard to mean that duplicate procedure names 
are not allowed, but we chose to do a vendor extension to allow duplicate 
procedure names and duplicate specific binding names.  With duplicate 
procedure names, I don't think there is any way you can get an ambiguous 
call in practice.  With duplicate specific binding names, if the bindings 
are in the same type, then you have duplicate procedure names.  If the 
bindings are in a parent type and an extending type, then the only 
difference between the two procedure interfaces is going to be pass object 
dummy argument.  So basically this means that if bindings S_d and S_s were 
not ambiguous in type A, there is no way for them to be ambiguous in child 
type B.  Of course, for this to work, the specific binding in the object's 
declared type has to "win" over the duplicate specific bindings in the 
other types.

So, in summary, I think the program is not conforming.  I think putting 
the generic binding only in the parent type will make it conforming and do 
what you want.  And I think the standard is unnecessarily strict in this 
case.

Regards

Rafik