http://d.puremagic.com/issues/show_bug.cgi?id=2524





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


-- 

Reply via email to