Clune, Thomas L. (GSFC-610.3) wrote:
>> It does not say that this is an obstacle to extending, in fact, the 
>> very fact the note exists means one can extend types with private 
>> type bound procedures.
>
> Unless, the standard intends this as a mechanism to prevent children 
> from overriding implementations.   And for cases other than generic, 
> deferred, I would say this appears to be the intent, which is probably 
> why this issue is getting interesting.

That's unlikely, since the NON_OVERRIDABLE attribute of a procedure 
binding is provided for this purpose.

We apparently need to clarify whether one can override a private 
procedure binding in a type extension in a different module from the one 
in which the base type is defined -- independently of whether the 
private binding is deferred.

I think it can be done (unless the private binding is NON_OVERRIDABLE), 
since USE association does not "get" the private names, and the 
overriding binding is the name of a new entity.  Whether it is deferred 
or not is irrelevant.  This is (IMO) no different from creating a new 
entity in a using scope that has the same name as a private entity that 
is not accessed from a used module -- necessarily not accessed because 
it cannot be accessed.  If one wanted to have a private nondeferred 
binding that cannot be overridden in an extension type defined in a 
module different from where the base type is defined, one should use 
both PRIVATE and NON_OVERRIDABLE, not just PRIVATE.

Of course, one can provide a binding with an entirely new name, and 
attach it to the same generic as the one to which the private (and 
deferred) bindings are attached.  Generic resolution works because 
corresponding arguments will necessarily have different types -- except 
perhaps if the private one and the new one both have NOPASS.  This 
doesn't override the private bindings, but at least if they are 
deferred, one cannot tell the difference between an overriding binding 
and an entirely new one, because one cannot have an object with an 
abstract dynamic type, and therefore cannot dispatch to a deferred binding.

Similarly, one could ask whether it is possible to have a data component 
in an extension of a type that is defined in a scoping unit that is 
different from the module where the base type is defined, if the base 
type has a private component of the same name.  Why not?  There's no way 
to confuse the two, since (a) the component in the extension type cannot 
be accessed in the module where the base type is defined (because we 
don't allow circular module dependencies) and (b) the component in the 
base type cannot be accessed anywhere the component in the extension 
type can be accessed (because it's private).  In fact, prohibiting it 
would cause inscrutable error messages, especially if documentation is 
provided only for the public components and bindings.  One would have to 
be clairvoyant to be sure to avoid using component names that duplicate 
private components (or private bindings) in the base type, including 
perhaps ones that come into existence in the future!

--

Van Snyder