Interface problems

[Steven Schveighoffer]

On Thu, 27 Jan 2011 09:26:28 -0500, Stanislav Blinov <blinov at loniir.ru>  
wrote:

> 26.01.2011 16:54, Steven Schveighoffer пишет:
>>
>> This is hardly a solution.  He wants to do value comparison, not  
>> identity comparison.
>>
>> The real fix is to make interface assume it is an Object, so it can be  
>> implicitly cast to Object, and find another way to implement COM  
>> interfaces.  The COM interface "hack" is way outdated and extremely  
>> harmful, esp. on OS' who *don't use COM*!  I can't see how the benefits  
>> it has outweigh the problems it causes.
>>
> The recent discussion in D group about destructor order brought me to  
> yet another question about interfaces.
> Currently, functions that should accept classes as parameters, e.g.  
> clear(), accept interfaces as well:
>
> void clear(T)(T obj) if (is(T == class)) // note the constraint
> { /*...*/ }
>
> interface I {}
> class A : I {}
> void main()
> {
>      I a = new A; // note that typeof(a) is I, not A
>      clear(a);
> }
>
> This compiles. But raises a question: how come? If it is assumed that a  
> reference to interface is not necessarily a D class instance, then it  
> shouldn't. The fact that it compiles even more ambiguates the purpose  
> and usage of interfaces.
> I agree with Steven. Having a support for COM, CORBA and so on in the  
> language is great, but wouldn't it be better to specify it explicitly?  
> Maybe solidify the usage of 'extern' keyword?
>
> interface D {} // instances are guaranteed to be D Objects
> extern interface E {} // instances may or may not be D Objects (COM and  
> alike)
>
> I mean, it's already there in the language and is described in  
> 'Interfacing to C++' in the documentation. Though currently, extern  
> interfaces are accepted by is(T == class) constraint as well.

It's because everywhere in the compiler, an interface is considered a  
class (I think even the type representing an interface is derived from the  
type representing class).  Except one, and that's implicit casting to  
Object.

My thought is, we already have extern(C++) interface, why not extern(COM)  
interface?  But we could even leave the notion of interfaces deriving from  
IUnknown as COM interfaces and just have the compiler check if an  
interface derives from IUnknown.  In fact, it *ALREADY DOES THIS* because  
it has to treat the layout of an IUnknown interface differently from  
another interface.  The whole argument to have interfaces not derive from  
Object because of COM is standing on such poor footing that I can't see  
how it's taken this long to fix.

-Steve