[Issue 2524] final override inconsistent when implementing interfaces
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Wed Jan 21 05:08:15 PST 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2524
------- Comment #13 from schveiguy at yahoo.com 2009-01-21 07:08 -------
(In reply to comment #12)
> (In reply to comment #10)
> > But I can still cast to the interface. Protection attributes are compile-time
> > entities, they are not flagged at runtime:
> >
> > SoundManager s;
> > Object o = s;
> >
> > INetworkListener inl = cast(INetworkListener)o;
> >
> > The compiler just looks in the object's list of interfaces to see if it finds
> > that interface. There is no protection associated with it at runtime.
>
> But the compiler is capable of checking to see whether the inheritance is
> public or private. It just doesn't at the moment. No runtime protection
> checking needed in this instance.
>
Casting to Object is valid, since the class did not inherit from Object
privately. Once you get to object, you need runtime information to cast to a
subclass or interface. If you're suggesting that an optimization can "see"
that the object originated from a SoundManager instance, then I can easily
generate a case where the cast to object and the cast to the interface are
hidden in opaque functions, eliminating the possibility of optimization.
I still contend that this cannot be checked at compile-time.
(In reply to comment #11)
> So what? How does this differ from the following in C++:
>
> [snip]
>
> You just hijacked type system, that's it.
No, I did not. Casting to an Object is a legal move within the type system.
It is equivalent to casting to a base class. Casting to an interface is also a
legal move, it is like a C++ dynamic_cast to a derived class. There is no
hijacking going on.
>
> One possible solution would be to add protection flag into class typeinfo which
> will be taken into account during dynamic cast. Or remove interface from
> classinfo.interfaces altogether (it should still be possible to cast known
> class to its known base class/interface statically, i.e. without dynamic cast).
I'm not sure this is possible, but I don't know completely the inner workings
of an interface cast. I think it's required that the interface vtable be
present in the class instance, and I think it's probably also required that it
be in the classinfo.
> I know the issue is not of high value but it should either be fixed for
> consistency, or protection inheritance attributes should be removed from
> language.
I would agree wholeheartedly that inheritance protection should be disallowed
for interfaces. I am not sure about inheritance protection for the base class,
I've never used it, and the documentation is completely absent (save for the
mention that it's valid syntax). I can't see a use case that couldn't be
solved by composition, or using private inner classes.
--
More information about the Digitalmars-d-bugs
mailing list