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.
