Interface problems

[Mandeep Singh Brar]

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.


Second this thought. Interface IMHO are far too basic for a functionality tweak.
Would also like to understand the way to raise such requests and take them to
their logical conclusion.

Regards
Mandeep