On 12/3/2012 9:17 AM, deadalnix wrote:
> I'm still waiting to see an object that implement an interface but that
> isn't a class instance.

COM objects that come from code not written in D.

Wouldn't it be better to return the class's typeinfo if it is a class and the interface's typeinfo if it isn't? The interface would then return the most derived typeinfo that it knows of. I think, just because the interface can be something other then a class object, doesn't mean it should be treated as though it will never be a class object.


On Mon, Dec 3, 2012 at 5:10 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 12/3/2012 6:26 AM, Gor Gyolchanyan wrote:
>
>> What's the logic in this behavior?
>>
>
> Think of it this way. An int can be implicitly converted to a long, but they have different typeid's because they are different bits.
>
>


-- 
Bye,
Gor Gyolchanyan.

On 12/3/2012 4:43 PM, Gor Gyolchanyan wrote:
> Wouldn't it be better to return the class's typeinfo if it is a class
> and the interface's typeinfo if it isn't? The interface would then
> return the most derived typeinfo that it knows of. I think, just because
> the interface can be something other then a class object, doesn't mean
> it should be treated as though it will never be a class object.

A particular interface can be implemented by many different class types, or by something that isn't even a class, so returning a typeid that's a class typeid would make it impossible to compare one with another.

On Monday, 3 December 2012 at 01:12:41 UTC, Walter Bright wrote:
>
>
> On 12/3/2012 9:17 AM, deadalnix wrote:
> > I'm still waiting to see an object that implement an
> interface but that
> > isn't a class instance.
>
> COM objects that come from code not written in D.

OK that make sense. I have to think about it.

On Monday, 3 December 2012 at 06:45:42 UTC, deadalnix wrote:
> On Monday, 3 December 2012 at 01:12:41 UTC, Walter Bright wrote:
>>
>>
>> On 12/3/2012 9:17 AM, deadalnix wrote:
>> > I'm still waiting to see an object that implement an
>> interface but that
>> > isn't a class instance.
>>
>> COM objects that come from code not written in D.
>
> OK that make sense. I have to think about it.

When coding against interfaces, it is always a good decision not to try to get back the object.

The main idea about using interfaces in first place is to have behavior independent of whatever class might implement it. If someone is trying to get back the implementation of a given interface, it is because the design is not sound in first place.

--
Paulo

Currently typeid(typeid(Interface)) == typeid(ClassInfo). So the interfaces are using a class's type info, which doesn't make much sense considering the aforementioned interface logic. If interfaces get their own type info (like one without a "base" member), it might have an a member called "objectType", which would be of type ClassInfo and would be null if the interface is not a class object. then the interface would be perfectly comparable with other interface types and in case it happens to be a class object, that could be tested too. And with some more info, the offset of the interface could be retrieved to compute the object's this reference (all in case it is indeed a class object).


On Mon, Dec 3, 2012 at 9:58 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 12/3/2012 4:43 PM, Gor Gyolchanyan wrote:
>
>> Wouldn't it be better to return the class's typeinfo if it is a class and the interface's typeinfo if it isn't? The interface would then return the most derived typeinfo that it knows of. I think, just because the interface can be something other then a class object, doesn't mean it should be treated as though it will never be a class object.
>>
>
> A particular interface can be implemented by many different class types, or by something that isn't even a class, so returning a typeid that's a class typeid would make it impossible to compare one with another.
>
>


-- 
Bye,
Gor Gyolchanyan.

On Monday, 3 December 2012 at 10:49:54 UTC, Gor Gyolchanyan wrote:
> Currently typeid(typeid(Interface)) == typeid(ClassInfo). So

Are you sure?

//dpaste seems to be down

import std.stdio;

interface I { }
class C: I { }

void main()
{
	I object = new C;
	writeln( typeid(object) == typeid(C) );
	writeln( typeid(Interface) == typeid(ClassInfo) );
	writeln( typeid(typeid(Interface)) == typeid(ClassInfo) );
}

Using latest dmd from git head I get three falses.

On 12/3/2012 9:47 PM, Gor Gyolchanyan wrote:
> Currently typeid(typeid(Interface)) == typeid(ClassInfo).

I'm curious what you expect typeid(typeid(something)) to do. I would expect it to return the typeid of whatever object typeid returns. That has nothing to do with what 'something' is.

On 2012-12-03 11:20, Paulo Pinto wrote:

> When coding against interfaces, it is always a good decision not to try
> to get back the object.
>
> The main idea about using interfaces in first place is to have behavior
> independent of whatever class might implement it. If someone is trying
> to get back the implementation of a given interface, it is because the
> design is not sound in first place.

Well, one would might think that this would work:

interface I {}

class A : I {}

void main ()
{
    I i = new A;
    Object o = i;
}

But it doesn't.

-- 
/Jacob Carlborg

On Monday, 3 December 2012 at 13:50:45 UTC, Jacob Carlborg wrote:
> On 2012-12-03 11:20, Paulo Pinto wrote:
>
>> When coding against interfaces, it is always a good decision not to try
>> to get back the object.
>>
>> The main idea about using interfaces in first place is to have behavior
>> independent of whatever class might implement it. If someone is trying
>> to get back the implementation of a given interface, it is because the
>> design is not sound in first place.
>
> Well, one would might think that this would work:
>
> interface I {}
>
> class A : I {}
>
> void main ()
> {
>     I i = new A;
>     Object o = i;
> }
>
> But it doesn't.

Object does not implement interface I, so why should interface instance be implicitly converted to it? It even should not be implicitly convertible to class if that class implements interface. However it is possible to use cast.

TDPL and dlang.org say almost nothing about it, but current investigated dmd behavior (http://dpaste.dzfl.pl/84637416) makes sense: it allows convenient conversion when it should happen, protects from poor implicit conversion which should not happen, but still allows to do what you want if you assume you are right. If you not, dmd punish you with segfault.