www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - typeid() broken for interfaces?

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--485b390f7a1642092d04cfb387f4
Content-Type: text/plain; charset=UTF-8

interface I { }
class C: I { }

I object = new C;
assert(typeid(object) == typeid(C)); // fails

Is this normal or is it a bug?
Note, that the same works fine in case of a base class, rather then an
interface.

-- 
Bye,
Gor Gyolchanyan.

--485b390f7a1642092d04cfb387f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>interface I { }</div><div>class C: I { }</div><div><br></div><div>I ob=
ject =3D new C;<br></div><div>assert(typeid(object) =3D=3D typeid(C)); // f=
ails</div><div><br></div><div>Is this normal or is it a bug?</div><div>Note=
, that the same works fine in case of a base class, rather then an interfac=
e.</div>
<div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br>

--485b390f7a1642092d04cfb387f4--
Nov 30 2012
next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Friday, 30 November 2012 at 10:05:21 UTC, Gor Gyolchanyan 
wrote:
 interface I { }
 class C: I { }

 I object = new C;
 assert(typeid(object) == typeid(C)); // fails

 Is this normal or is it a bug?
 Note, that the same works fine in case of a base class, rather 
 then an
 interface.

It works according to spec. Object is expression of type interface I, so no dynamic type search is performed.
Nov 30 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--bcaec54fb9c6f8f89b04cfb45ac1
Content-Type: text/plain; charset=UTF-8

So the interfaces aren't supposed to hold a TypeInfo? That doesn't sound
right. That makes interfaces useless in a very large set of use cases.


On Fri, Nov 30, 2012 at 2:55 PM, Maxim Fomin <maxim maxim-fomin.ru> wrote:

 On Friday, 30 November 2012 at 10:05:21 UTC, Gor Gyolchanyan wrote:

 interface I { }
 class C: I { }

 I object = new C;
 assert(typeid(object) == typeid(C)); // fails

 Is this normal or is it a bug?
 Note, that the same works fine in case of a base class, rather then an
 interface.

It works according to spec. Object is expression of type interface I, so no dynamic type search is performed.

-- Bye, Gor Gyolchanyan. --bcaec54fb9c6f8f89b04cfb45ac1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So the interfaces aren&#39;t supposed to hold a TypeInfo? That doesn&#39;t = sound right. That makes interfaces useless in a very large set of use cases= .<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Nov = 30, 2012 at 2:55 PM, Maxim Fomin <span dir=3D"ltr">&lt;<a href=3D"mailto:ma= xim maxim-fomin.ru" target=3D"_blank">maxim maxim-fomin.ru</a>&gt;</span> w= rote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Friday, 30 November 201= 2 at 10:05:21 UTC, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> interface I { }<br> class C: I { }<br> <br> I object =3D new C;<br> assert(typeid(object) =3D=3D typeid(C)); // fails<br> <br> Is this normal or is it a bug?<br> Note, that the same works fine in case of a base class, rather then an<br> interface.<br> </blockquote> <br></div> It works according to spec. Object is expression of type interface I, so no= dynamic type search is performed.<br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --bcaec54fb9c6f8f89b04cfb45ac1--
Nov 30 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Friday, 30 November 2012 at 11:04:10 UTC, Gor Gyolchanyan 
wrote:
 So the interfaces aren't supposed to hold a TypeInfo? That 
 doesn't sound
 right. That makes interfaces useless in a very large set of use 
 cases.

You can find information about interfaces and classes at http://dlang.org/abi.html (interfaces have a pointer to vtbl[] which entries have pointers to TypeInfo). You can also write enhancement request if you consider your proposal worth implementing (but I don't understand what exactly you want).
Nov 30 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2012 9:04 PM, Gor Gyolchanyan wrote:
 interface I { }
 class C: I { }

 I object = new C;
 assert(typeid(object) == typeid(C)); // fails

 Is this normal or is it a bug?

Normal, since the typeids of interfaces are not the same as for classes.
 Note, that the same works fine in case of a base class, rather then an
 interface.

That works, because classes are classes. Classes are not interfaces.
Dec 01 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 02 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 02 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 03 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 02 2012
parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 03 2012
parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 03 2012
parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 03 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 03 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 03 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-03 21:59, Walter Bright wrote:

 But not all interfaces come from Objects.

No, but those are statically known. -- /Jacob Carlborg
Dec 03 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-04 13:15, foobar wrote:

 IMO this is a design mistake - the special case is preferred over the
 common case which goes against the D philosophy of making the common
 case easy and the special case possible.

 All COM instances are known at _compile_time_ as they're all required to
 inherit from a special IUnknown interface so the compiler _knows_ if
 indeed an interface represents a COM instance or not. This can be used
 to handle this special case differently.

 Interface i = new Class();
 Object o = i; // should work for regular interfaces

 The compiler can issue a compile-time error if i is COM since this is
 known at compile type.

Exactly, I couldn't agree more. -- /Jacob Carlborg
Dec 04 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-04 09:22, Maxim Fomin wrote:

 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));
 }

You get a segmentation fault since both "i" and "o" are null.
 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

You cannot really get an instance of an interface without having a class implementing it. That is, without inserting any explicit casts, which works: interface I { } class A { } void main() { A a = new A; I i = cast(I) a; Object o = cast(Object)i; writeln(typeid(a)); // A }
 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.

I don't understand why it wouldn't be safe to allow implicit casts of interfaces to Object. If I want to call toString, why should I need to insert an explicit cast to Object just because I have an interface? -- /Jacob Carlborg
Dec 04 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0401240b78854504cfe39c3d
Content-Type: text/plain; charset=UTF-8

What's the logic in this behavior?


On Sun, Dec 2, 2012 at 1:28 AM, Walter Bright <newshound2 digitalmars.com>wrote:

 On 11/30/2012 9:04 PM, Gor Gyolchanyan wrote:

 interface I { }
 class C: I { }

 I object = new C;
 assert(typeid(object) == typeid(C)); // fails

 Is this normal or is it a bug?

Normal, since the typeids of interfaces are not the same as for classes. Note, that the same works fine in case of a base class, rather then an
 interface.

That works, because classes are classes. Classes are not interfaces.

-- Bye, Gor Gyolchanyan. --f46d0401240b78854504cfe39c3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What&#39;s the logic in this behavior?<div class=3D"gmail_extra"><br><br><d= iv class=3D"gmail_quote">On Sun, Dec 2, 2012 at 1:28 AM, Walter Bright <spa= n dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_= blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On 11/30/2012 9:04 PM, Gor= Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> interface I { }<br> class C: I { }<br> <br> I object =3D new C;<br> assert(typeid(object) =3D=3D typeid(C)); // fails<br> <br> Is this normal or is it a bug?<br> </blockquote> <br></div> Normal, since the typeids of interfaces are not the same as for classes.<di= v class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Note, that the same works fine in case of a base class, rather then an<br> interface.<br> </blockquote> <br></div> That works, because classes are classes. Classes are not interfaces.<br> <br> <br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --f46d0401240b78854504cfe39c3d--
Dec 02 2012
prev sibling next sibling parent "pjmlp" <pjmlp progtools.org> writes:
On Sunday, 2 December 2012 at 19:26:47 UTC, Gor Gyolchanyan wrote:
 What's the logic in this behavior?


 On Sun, Dec 2, 2012 at 1:28 AM, Walter Bright 
 <newshound2 digitalmars.com>wrote:

 On 11/30/2012 9:04 PM, Gor Gyolchanyan wrote:

 interface I { }
 class C: I { }

 I object = new C;
 assert(typeid(object) == typeid(C)); // fails

 Is this normal or is it a bug?

Normal, since the typeids of interfaces are not the same as for classes. Note, that the same works fine in case of a base class, rather then an
 interface.

That works, because classes are classes. Classes are not interfaces.


Because interfaces don't extend object?
Dec 02 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 1 December 2012 at 21:28:05 UTC, Walter Bright wrote:
 On 11/30/2012 9:04 PM, Gor Gyolchanyan wrote:
 interface I { }
 class C: I { }

 I object = new C;
 assert(typeid(object) == typeid(C)); // fails

 Is this normal or is it a bug?

Normal, since the typeids of interfaces are not the same as for classes.
 Note, that the same works fine in case of a base class, rather 
 then an
 interface.

That works, because classes are classes. Classes are not interfaces.

I'm still waiting to see an object that implement an interface but that isn't a class instance.
Dec 02 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 02, 2012 23:17:33 deadalnix wrote:
 I'm still waiting to see an object that implement an interface
 but that isn't a class instance.

Isn't that the case with the COM stuff? I remember there being something weird about them being interfaces but not classes, which is part of what has screwed over some of the interface-related stuff like opEquals. - Jonathan M Davis
Dec 02 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--bcaec54ee8a442b55404cfec3b5a
Content-Type: text/plain; charset=UTF-8

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. --bcaec54ee8a442b55404cfec3b5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wouldn&#39;t it be better to return the class&#39;s typeinfo if it is a cla= ss and the interface&#39;s typeinfo if it isn&#39;t? The interface would th= en return the most derived typeinfo that it knows of. I think, just because= the interface can be something other then a class object, doesn&#39;t mean= it should be treated as though it will never be a class object.<div class= =3D"gmail_extra"> <br><br><div class=3D"gmail_quote">On Mon, Dec 3, 2012 at 5:10 AM, Walter B= right <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" t= arget=3D"_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"> <div class=3D"im">On 12/3/2012 6:26 AM, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What&#39;s the logic in this behavior?<br> </blockquote> <br></div> Think of it this way. An int can be implicitly converted to a long, but the= y have different typeid&#39;s because they are different bits.<br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --bcaec54ee8a442b55404cfec3b5a--
Dec 02 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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

 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.
Dec 02 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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

 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
Dec 03 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d04308554fc456804cff07926
Content-Type: text/plain; charset=UTF-8

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. --f46d04308554fc456804cff07926 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Currently typeid(typeid(Interface)) =3D=3D typeid(ClassInfo). So the interf= aces are using a class&#39;s type info, which doesn&#39;t make much sense c= onsidering the aforementioned interface logic. If interfaces get their own = type info (like one without a &quot;base&quot; member), it might have an a = member called &quot;objectType&quot;, which would be of type ClassInfo and = would be null if the interface is not a class object. then the interface wo= uld be perfectly comparable with other interface types and in case it happe= ns 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&#39;s= this reference (all in case it is indeed a class object).<div class=3D"gma= il_extra"> <br><br><div class=3D"gmail_quote">On Mon, Dec 3, 2012 at 9:58 AM, Walter B= right <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" t= arget=3D"_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"> <div class=3D"im">On 12/3/2012 4:43 PM, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Wouldn&#39;t it be better to return the class&#39;s typeinfo if it is a cla= ss<br> and the interface&#39;s typeinfo if it isn&#39;t? The interface would then<= br> return the most derived typeinfo that it knows of. I think, just because<br=

br> it should be treated as though it will never be a class object.<br> </blockquote> <br></div> A particular interface can be implemented by many different class types, or= by something that isn&#39;t even a class, so returning a typeid that&#39;s= a class typeid would make it impossible to compare one with another.<br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan.<br> </div> --f46d04308554fc456804cff07926--
Dec 03 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Dec 03 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Dec 03 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Dec 03 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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).
Dec 03 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Dec 03 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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 }
Dec 04 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Dec 04 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 4 December 2012 at 07:38:31 UTC, Maxim Fomin wrote:
 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.

Given my experience with the interface concept in several OO languages that implement it, I would say that you never want to know what object was given to you. The whole point of interfaces is to have some form of multiple inheritance in single inheritance languages. So you *really* don't want to cast interfaces to objects. I can't think of a single reason this makes sense, other than work around bad designs. -- Paulo
Dec 04 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
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.

IMO this is a design mistake - the special case is preferred over the common case which goes against the D philosophy of making the common case easy and the special case possible. All COM instances are known at _compile_time_ as they're all required to inherit from a special IUnknown interface so the compiler _knows_ if indeed an interface represents a COM instance or not. This can be used to handle this special case differently. Interface i = new Class(); Object o = i; // should work for regular interfaces The compiler can issue a compile-time error if i is COM since this is known at compile type.
Dec 04 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Tuesday, 4 December 2012 at 07:38:31 UTC, Maxim Fomin wrote:
 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.

The above is a perfectly safe conversion. The variable i is _a reference_ to instance of I. since it was not assigned any class instance that implements I, it is initialized as _null_. In the example above: (o is null && typeid(o) == typeid(Object))
Dec 04 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 4 December 2012 at 12:26:53 UTC, Jacob Carlborg wrote:
 On 2012-12-04 09:22, Maxim Fomin wrote:

 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));
 }

You get a segmentation fault since both "i" and "o" are null.
 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

You cannot really get an instance of an interface without having a class implementing it. That is, without inserting any explicit casts, which works: interface I { } class A { } void main() { A a = new A; I i = cast(I) a; Object o = cast(Object)i; writeln(typeid(a)); // A }
 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.

I don't understand why it wouldn't be safe to allow implicit casts of interfaces to Object. If I want to call toString, why should I need to insert an explicit cast to Object just because I have an interface?

If you want to call toSring, it should be part of the interface specification, as simple as that. Interfaces are like contracts which state what is to be expected of a certain type. -- Paulo
Dec 04 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Tuesday, 4 December 2012 at 12:30:29 UTC, Paulo Pinto wrote:
 On Tuesday, 4 December 2012 at 12:26:53 UTC, Jacob Carlborg 
 wrote:
 On 2012-12-04 09:22, Maxim Fomin wrote:

 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));
 }

You get a segmentation fault since both "i" and "o" are null.
 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

You cannot really get an instance of an interface without having a class implementing it. That is, without inserting any explicit casts, which works: interface I { } class A { } void main() { A a = new A; I i = cast(I) a; Object o = cast(Object)i; writeln(typeid(a)); // A }
 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.

I don't understand why it wouldn't be safe to allow implicit casts of interfaces to Object. If I want to call toString, why should I need to insert an explicit cast to Object just because I have an interface?

If you want to call toSring, it should be part of the interface specification, as simple as that. Interfaces are like contracts which state what is to be expected of a certain type. -- Paulo

Generally speaking you are right. But specifically regarding toString, what would you suggest? Should each and every Interface have a toString method? Should we have an IObject Interface that all classes are required to explicitly inherit? The purpose of having a root Object class is to define the _common interface of all objects_. Why else have such a class in the first place? Requiring an explicit cast to Object makes sense only in a no-single-root design such as the one in c++ which D sensibly chose not to copy. We can have a separate debate what should the root Object define, but there should not be a requirement to explicitly cast any object to it.
Dec 04 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 4 December 2012 at 13:07:59 UTC, foobar wrote:
 On Tuesday, 4 December 2012 at 12:30:29 UTC, Paulo Pinto wrote:
 On Tuesday, 4 December 2012 at 12:26:53 UTC, Jacob Carlborg 
 wrote:
 On 2012-12-04 09:22, Maxim Fomin wrote:

 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));
 }

You get a segmentation fault since both "i" and "o" are null.
 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

You cannot really get an instance of an interface without having a class implementing it. That is, without inserting any explicit casts, which works: interface I { } class A { } void main() { A a = new A; I i = cast(I) a; Object o = cast(Object)i; writeln(typeid(a)); // A }
 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.

I don't understand why it wouldn't be safe to allow implicit casts of interfaces to Object. If I want to call toString, why should I need to insert an explicit cast to Object just because I have an interface?

If you want to call toSring, it should be part of the interface specification, as simple as that. Interfaces are like contracts which state what is to be expected of a certain type. -- Paulo

Generally speaking you are right. But specifically regarding toString, what would you suggest? Should each and every Interface have a toString method?

Yes for each interface where you intend to call toString().
 Should we have an IObject Interface that all classes are 
 required to explicitly inherit?
 The purpose of having a root Object class is to define the 
 _common interface of all objects_. Why else have such a class 
 in the first place?

For languages without generics where you need a common base class to place in containers.
 Requiring an explicit cast to Object makes sense only in a 
 no-single-root design such as the one in c++ which D sensibly 
 chose not to copy.

 We can have a separate debate what should the root Object 
 define, but there should not be a requirement to explicitly 
 cast any object to it.

The whole point of interfaces is to have explicit dependencies of methods, properties, variables across the inheritance tree. Actually there was a discussion some months ago about what methods still made sense to expose via object, given D's templates. -- Paulo
Dec 04 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Tuesday, 4 December 2012 at 13:47:39 UTC, Paulo Pinto wrote:

 Generally speaking you are right. But specifically regarding 
 toString, what would you suggest?
 Should each and every Interface have a toString method?

Yes for each interface where you intend to call toString().

That's a lot of duplication considering D already provides this in Object.
 Should we have an IObject Interface that all classes are 
 required to explicitly inherit?
 The purpose of having a root Object class is to define the 
 _common interface of all objects_. Why else have such a class 
 in the first place?

For languages without generics where you need a common base class to place in containers.

That's only one reason. Other reasons are to provide a common interface for all objects. Anyway, we are discussing the current D design and not other possible designs such as the one in C++.
 Requiring an explicit cast to Object makes sense only in a 
 no-single-root design such as the one in c++ which D sensibly 
 chose not to copy.

 We can have a separate debate what should the root Object 
 define, but there should not be a requirement to explicitly 
 cast any object to it.

The whole point of interfaces is to have explicit dependencies of methods, properties, variables across the inheritance tree. Actually there was a discussion some months ago about what methods still made sense to expose via object, given D's templates. -- Paulo

Given D's _current_ design, all objects should implicitly cast to Object. It's plain common sense - If we have a root class that all other classes inherit from than it logically follows that all class instances can be implicitly & safely converted back to that root class (Object). What you are arguing is whether the current design of D of defining Object makes sense in the first place. I'm arguing that _given the current design_ the language is inconsistent and has a design flaw.
Dec 04 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, December 04, 2012 17:35:23 foobar wrote:
 That's a lot of duplication considering D already provides this
 in Object.

Though per the last major discussion on const-correctness and Object, it's likely that toString, toHash, opCmp, and opEquals will be removed from Object, in which case you'd need a derived class which implemented them to use any of them. - Jonathan m Davis
Dec 04 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis 
wrote:
 On Tuesday, December 04, 2012 17:35:23 foobar wrote:
 That's a lot of duplication considering D already provides this
 in Object.

Though per the last major discussion on const-correctness and Object, it's likely that toString, toHash, opCmp, and opEquals will be removed from Object, in which case you'd need a derived class which implemented them to use any of them. - Jonathan m Davis

In other words, the plan is to pretty much deprecate Object? I hope there would be appropriate replacement before this happens. Users should be able to have a standardized API and a default implementation for these methods. Is phobos going to introduce interface such as Printable, Comparable, etc.. ? (names tentative, I'm more worried about the semantics).
Dec 05 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis 
wrote:
 On Tuesday, December 04, 2012 17:35:23 foobar wrote:
 That's a lot of duplication considering D already provides this
 in Object.

Though per the last major discussion on const-correctness and Object, it's likely that toString, toHash, opCmp, and opEquals will be removed from Object, in which case you'd need a derived class which implemented them to use any of them. - Jonathan m Davis

In other words, the plan is to pretty much deprecate Object? I hope there would be appropriate replacement before this happens. Users should be able to have a standardized API and a default implementation for these methods. Is phobos going to introduce interface such as Printable, Comparable, etc.. ? (names tentative, I'm more worried about the semantics).
Dec 05 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis 
wrote:
 On Tuesday, December 04, 2012 17:35:23 foobar wrote:
 That's a lot of duplication considering D already provides this
 in Object.

Though per the last major discussion on const-correctness and Object, it's likely that toString, toHash, opCmp, and opEquals will be removed from Object, in which case you'd need a derived class which implemented them to use any of them. - Jonathan m Davis

In other words, the plan is to pretty much deprecate Object? I hope there would be appropriate replacement before this happens. Users should be able to have a standardized API and a default implementation for these methods. Is phobos going to introduce interfaces such as Printable, Comparable, etc.. ? (names tentative, I'm more worried about the semantics).
Dec 05 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 05, 2012 15:11:55 foobar wrote:
 On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis
 
 wrote:
 On Tuesday, December 04, 2012 17:35:23 foobar wrote:
 That's a lot of duplication considering D already provides this
 in Object.

Though per the last major discussion on const-correctness and Object, it's likely that toString, toHash, opCmp, and opEquals will be removed from Object, in which case you'd need a derived class which implemented them to use any of them. - Jonathan m Davis

In other words, the plan is to pretty much deprecate Object? I hope there would be appropriate replacement before this happens. Users should be able to have a standardized API and a default implementation for these methods. Is phobos going to introduce interface such as Printable, Comparable, etc.. ? (names tentative, I'm more worried about the semantics).

No. The plan is not to deprecate Object. The reality is that those functions don't need to be on Object in D, because all of the runtime stuff that relies on them can (and really should) be templatized, whereas in Java or C#, they have to put them on Object and operate through Object. What we have currently have with Object in D is a case of having copied too much from Java and C# (and templates weren't as good in D1, possibly making those functions necessary there). And having those functions on Object has created a lot of problems with regards to stuff like const. If they're there, they have to be const so that you can compare const objects, but given how D's const works, that then make certain idioms impossible in classes (e.g. lazy loading member variables and caching). const needs to work, but we can't force it on people, and putting it on Object forces it on people. Rather, it's perfectly possible for only derived classes to have those functions. They can then use the function attributes that match what they need, and stuff like druntime's opEquals or AAs will just be appropriately tempatized and work with the derived classes without needing to have any of that on Object. There's really no need to have any of that on Object. I'd have to go digging through the archives to find the last discussion on const-correctness where this was discussed in some detail, but that's the gist of it. Putting those functions on Object causes a lot of problems with regards to function attributes, and templates make actually putting those functions on Object unnecessary. - Jonathan M Davis
Dec 05 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Wednesday, 5 December 2012 at 16:21:55 UTC, Jonathan M Davis 
wrote:
 On Wednesday, December 05, 2012 15:11:55 foobar wrote:
 On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis
 
 wrote:
 On Tuesday, December 04, 2012 17:35:23 foobar wrote:
 That's a lot of duplication considering D already provides 
 this
 in Object.

Though per the last major discussion on const-correctness and Object, it's likely that toString, toHash, opCmp, and opEquals will be removed from Object, in which case you'd need a derived class which implemented them to use any of them. - Jonathan m Davis

In other words, the plan is to pretty much deprecate Object? I hope there would be appropriate replacement before this happens. Users should be able to have a standardized API and a default implementation for these methods. Is phobos going to introduce interface such as Printable, Comparable, etc.. ? (names tentative, I'm more worried about the semantics).

No. The plan is not to deprecate Object. The reality is that those functions don't need to be on Object in D, because all of the runtime stuff that relies on them can (and really should) be templatized, whereas in Java or C#, they have to put them on Object and operate through Object. What we have currently have with Object in D is a case of having copied too much from Java and C# (and templates weren't as good in D1, possibly making those functions necessary there). And having those functions on Object has created a lot of problems with regards to stuff like const. If they're there, they have to be const so that you can compare const objects, but given how D's const works, that then make certain idioms impossible in classes (e.g. lazy loading member variables and caching). const needs to work, but we can't force it on people, and putting it on Object forces it on people. Rather, it's perfectly possible for only derived classes to have those functions. They can then use the function attributes that match what they need, and stuff like druntime's opEquals or AAs will just be appropriately tempatized and work with the derived classes without needing to have any of that on Object. There's really no need to have any of that on Object. I'd have to go digging through the archives to find the last discussion on const-correctness where this was discussed in some detail, but that's the gist of it. Putting those functions on Object causes a lot of problems with regards to function attributes, and templates make actually putting those functions on Object unnecessary. - Jonathan M Davis

But these are the methods of Object. So even if Object itself remains it looses its meaning. So are we going to keep Object just for backwards compatibility? Is there any point left keeping the single root design?
Dec 06 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, December 06, 2012 12:03:14 foobar wrote:
 But these are the methods of Object. So even if Object itself
 remains it looses its meaning. So are we going to keep Object
 just for backwards compatibility? Is there any point left keeping
 the single root design?

It's would still be perfectly possible to pass around Object if you wanted to. You just couldn't call much on it without casting it to something else first. Perhaps there's less reason to have it, but no one ever suggested that we get rid of it. Having those functions on Object has harmed us. Having a common base type hasn't. But much as it was decided on, nothing has happened yet, so who knows how the transition will be done. - Jonathan M Davis
Dec 06 2012
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 6 December 2012 at 11:03:15 UTC, foobar wrote:
 But these are the methods of Object. So even if Object itself 
 remains it looses its meaning. So are we going to keep Object 
 just for backwards compatibility? Is there any point left 
 keeping the single root design?

I don't see any major drawback in keeping Object. What are the drawbacks ?
Dec 06 2012