On Feb 10, 2008, at 12:37 AM, 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. It
> merely states a fact that private bindings are inaccesible directly
> by reference---they are accessible when doing table dispatch
> internally in the compiler.
OK.
> Remember that private only refers to names, not actual physical
> accessibility.
OK, but to provide implementations in the subclass, one needs their
names. (See thread with Malcolm - placing within a single module
avoids the problem, but still requires use of the private names to
provide an implementation.)
> 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.
> Somehow deferred bindings may be different, but I don't see why
> (and I was the one that proposed added deferred bindings in F2003,
> for what that's worth).
You have my gratitude. I suppose I could get used to nondeferred
methods in abstract classes that just throw exceptions, but deferred
is far more elegant.
> The general principle should always be not to forbid things unless
> there is a good reason.
Agreed.
>
>> 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).
Unfortunately, as much as I am a lifetime user and defender of
Fortran, I may have pinned too many hopes on these OO features.
I am running into a fair number of things which will not quite work
without terrible sacrifices - many of them boiling down to putting
whole suites of classes into one module.
>
> Disclaimer: This opinion is not based upon digging through the
> standard, mostly on recollection, so I may well be wrong.
>
> Thanks,
> Aleks
Cheers,
- Tom
|