------- Comment #13 from  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.


Reply via email to