View mode: basic / threaded / horizontal-split · Log in · Help
December 03, 2012
Re: typeid() broken for interfaces?
On 2012-12-03 15:41, Maxim Fomin wrote:

> 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.

Because Object is the root of the class hierarchy. That's how it works 
in Java, for example. It's just because of these COM interfaces, that 
are not D interfaces, that we have this behavior.

-- 
/Jacob Carlborg
December 03, 2012
Re: typeid() broken for interfaces?
On 2012-12-03 16:51, Jacob Carlborg wrote:

> Because Object is the root of the class hierarchy. That's how it works
> in Java, for example. It's just because of these COM interfaces, that
> are not D interfaces, that we have this behavior.

Note, I'm not saying that an interface should be implicitly converted to 
any class, only to Object.

-- 
/Jacob Carlborg
December 03, 2012
Re: typeid() broken for interfaces?
On 12/4/2012 2:52 AM, Jacob Carlborg wrote:
> Note, I'm not saying that an interface should be implicitly converted to
> any class, only to Object.


But not all interfaces come from Objects.
December 03, 2012
Re: typeid() broken for interfaces?
On Monday, 3 December 2012 at 20:59:24 UTC, Walter Bright wrote:
> On 12/4/2012 2:52 AM, Jacob Carlborg wrote:
>> Note, I'm not saying that an interface should be implicitly 
>> converted to
>> any class, only to Object.
>
>
> But not all interfaces come from Objects.

So I thought about all that.

typeid is about runtime type detection. As all interfaces are not 
coming from object, it is definitively an issue to resolve them 
as object sometime. However, keeping tied to the static type when 
runtime typeid is asked for is a but sad.

But interfaces that don't resolve as object are well know at 
compile time. So isn't it possible to resolve all interfaces that 
we know are objects into object's typeid ? After all, this is 
what typeid is about.
December 03, 2012
Re: typeid() broken for interfaces?
On 12/4/2012 8:07 AM, deadalnix wrote:
> On Monday, 3 December 2012 at 20:59:24 UTC, Walter Bright wrote:
>> On 12/4/2012 2:52 AM, Jacob Carlborg wrote:
>>> Note, I'm not saying that an interface should be implicitly converted to
>>> any class, only to Object.
>>
>>
>> But not all interfaces come from Objects.
>
> So I thought about all that.
>
> typeid is about runtime type detection. As all interfaces are not coming
> from object, it is definitively an issue to resolve them as object
> sometime. However, keeping tied to the static type when runtime typeid
> is asked for is a but sad.
>
> But interfaces that don't resolve as object are well know at compile
> time.
> So isn't it possible to resolve all interfaces that we know are
> objects into object's typeid ? After all, this is what typeid is about.

I really don't know what issue you're trying to solve here. The typeid's 
work fine - and interfaces are not objects. Having the typeid for an 
interface be an object means you cannot compare typeids of one interface 
to another interface.

And, my feeling is that if your code needs to implicitly convert 
interfaces to objects, or even know that an interface instance is 
implemented by a particular object, your program design is broken and is 
missing the point of what interfaces are.
December 03, 2012
Re: typeid() broken for interfaces?
On Monday, 3 December 2012 at 21:53:47 UTC, Walter Bright wrote:
> I really don't know what issue you're trying to solve here. The 
> typeid's work fine - and interfaces are not objects. Having the 
> typeid for an interface be an object means you cannot compare 
> typeids of one interface to another interface.
>

You can't instantiate interface. So an underlying type MUST 
exist. The whole point of typeid on expression is to discover 
what is the dynamic type of things, otherwize you'd be using 
typeid(type) not typeid(expression).

> And, my feeling is that if your code needs to implicitly 
> convert interfaces to objects, or even know that an interface 
> instance is implemented by a particular object, your program 
> design is broken and is missing the point of what interfaces 
> are.

The same apply to object in general, and still D does it and for 
good reason (you'll find that few cases where it is actually 
useful and not a design flaw).
December 04, 2012
Re: typeid() broken for interfaces?
On 2012-12-03 21:59, Walter Bright wrote:

> But not all interfaces come from Objects.

No, but those are statically known.

-- 
/Jacob Carlborg
December 04, 2012
Re: typeid() broken for interfaces?
On Monday, 3 December 2012 at 23:53:26 UTC, deadalnix wrote:
> On Monday, 3 December 2012 at 21:53:47 UTC, Walter Bright wrote:
>> I really don't know what issue you're trying to solve here. 
>> The typeid's work fine - and interfaces are not objects. 
>> Having the typeid for an interface be an object means you 
>> cannot compare typeids of one interface to another interface.
>>
>
> You can't instantiate interface. So an underlying type MUST 
> exist. The whole point of typeid on expression is to discover 
> what is the dynamic type of things, otherwize you'd be using 
> typeid(type) not typeid(expression).

You cannot create interface instance with new operator because 
interface object is not valid until it is actually some class 
instance. But this does not mean neither that typeid operator for 
interfaces should return dynamic type nor that interface can be 
implicitly converted to Object - because interface instance may 
be invalid:

import std.stdio;

interface I { }

void main()
{
	I i;
        // should be implicitly converted
	Object o = cast(Object)i;
	writeln(typeid(o));
}

and because presence of interface does not necessarily mean that 
some class has implemented it.

This makes casting interfaces to object unsafe operation that 
better should require explicit cast.
December 04, 2012
Re: typeid() broken for interfaces?
On Monday, 3 December 2012 at 15:52:24 UTC, Jacob Carlborg wrote:
> On 2012-12-03 16:51, Jacob Carlborg wrote:
>
>> Because Object is the root of the class hierarchy. That's how 
>> it works
>> in Java, for example. It's just because of these COM 
>> interfaces, that
>> are not D interfaces, that we have this behavior.
>
> Note, I'm not saying that an interface should be implicitly 
> converted to any class, only to Object.

And what happens if nobody implements an interface?

import std.stdio;

interface I { }

class A { }

void main()
{
	I i;
	// assume this is implicit
	Object o = cast(Object)i;
	writeln(typeid(o));
}

Safe conversion class to interface requires two conditions:
1a) that class implements interface
1b) if you try to use interface variable, it must be an allocated 
class instance

Safe conversion to Object requires:
2a) somebody in class hierarchy implements interface
2b) interface instance is actually allocated class instance

It is possible to check 1a) but impossible in general case to 
check 2a). Also the first is design feature while the second is 
design abuse.

And if there is need for getting runtime type of interface 
through typeid() it is always possible to use cast:

import std.stdio;

interface I { }

class A : I { }

void main()
{
	A a = new A;
	I i = a;
	Object o = cast(Object)i;
	writeln(typeid(o)); // A
}
December 04, 2012
Re: typeid() broken for interfaces?
On Tuesday, 4 December 2012 at 08:22:36 UTC, Maxim Fomin wrote:
> On Monday, 3 December 2012 at 15:52:24 UTC, Jacob Carlborg 
> wrote:
>> On 2012-12-03 16:51, Jacob Carlborg wrote:
>>
>>> Because Object is the root of the class hierarchy. That's how 
>>> it works
>>> in Java, for example. It's just because of these COM 
>>> interfaces, that
>>> are not D interfaces, that we have this behavior.
>>
>> Note, I'm not saying that an interface should be implicitly 
>> converted to any class, only to Object.
>
> And what happens if nobody implements an interface?
>

The same as abstract classes : you can get the typeid by looking 
at it throw child's typeid or typeid(type).

typeid(expression) will never return them because they can't be 
instantiated.
1 2 3 4 5
Top | Discussion index | About this forum | D home