Interface problems

[Stanislav Blinov]

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.