Aleksandar Donev wrote:
> Hi,
>
>> Error: oo_style.F90, line 31: Cannot extend abstract type
>> ABSTRACTVISITOR because it has a private deferred type-bound
>> procedure VISITREAL
> Helpful :-)
>
>> The section of the standard that seems to support this notion is in
>> section 4.5.6.1 Inheritance:
>>
>> NOTE 4.51
>> Inaccessible components and bindings of the parent type are also
>> inherited, but they remain inaccessible in the extended type.
> This is a note and it does not support the above error message....
>
>> I guess that it hinges on whether providing an actual procedure in
>> place of a deferred counts as "accessing".
> Overriding a binding would require specifying the name, which is what
> private forbids (it hides the name). But this is not to say that you
> are not allowed to extend the type in the first place (although, as
> you can see, it makes it impossible to make the type non-abstract by
> actually providing specific bindings, so you should probably rethink
> your approach anyway).
If you have a type in one module and it has a private binding,
overriding that binding in a different module uses the same binding
name. But the binding name in the extension is the name of a different
entity. So the appearance of that name shouldn't count as an attempt to
"access" the name of the private binding. The processor, of course,
"accesses" the private binding to deterrmine whether you're overriding
it, or creating an entirely new binding with a new name, but the
processor can do that without violating the privacy rules. If you had
overridden a private deferred binding with another deferred binding, or
indeed hadn't overridden a deferred binding, your extension type would
still be abstract, but that's a different consideration from whether you
can override a private binding in a different module. If you tried to
create a generic using the private binding, in an extension of the base
type in a different module from where the base type is defined, that
would be prohibited because you'd be accessing the private name.
This is a similar question to what happens if you have a private name in
a module (not a component or binding, just an ordinary name, such as a
variable name), you use that module without an ONLY clause, and then the
using scoping unit creates an entity with the same name. Does that
violate the privacy rules or not? If the name in the used module were
public, trying to create an entity of the same name in the using scoping
unit would violate the naming rules. If it's private you can't access
the name by use association. Does that mean you DON'T access it if you
don't have an ONLY clause? Can you create a new entity of the same name
in the using scoping unit?
I think you can override a private binding in a different module from
the one containing the base type's definition, and I think you can
create a new entity in a using scoping unit having the same name as a
private entity in a used module, even without an ONLY clause that
doesn't (because it can't) list the private name. But... I haven't done
any research on these questions because there's a good chance that
somebody who reads this list knows the answer without needing to do
research.
If there's controversy, maybe we need an official interpretation whether
overriding a private binding in a different module from the one
containing the base type's definition constitutes access to the private
name, and is therefore forbidden, or it doesn't constitute an access and
is therefore allowed.
|