www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Confused about interfaces in D

reply Thomas Leonard <talex5+d gmail.com> writes:
Hi,

I'm used to interfaces in Java, and I'm wondering why this doesn't work 
in D:

  interface Clock {}

  class SystemClock : Clock {}

  void main(string[] args) {
	Clock c = new SystemClock();
	c.toString();
  }

It says:

  $ dmd clock.d
  clock.d(7): Error: no property 'toString' for type 'clock.Clock'

This compiles, though:

	Clock c = new SystemClock();
	(cast(Object) c).toString();

When is a "Clock" not an "Object"?

Thanks,
Oct 01 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 2, 2008 at 5:59 AM, Thomas Leonard <talex5+d gmail.com> wrote:
 Hi,

 I'm used to interfaces in Java, and I'm wondering why this doesn't work
 in D:

  interface Clock {}

  class SystemClock : Clock {}

  void main(string[] args) {
        Clock c = new SystemClock();
        c.toString();
  }

 It says:

  $ dmd clock.d
  clock.d(7): Error: no property 'toString' for type 'clock.Clock'

 This compiles, though:

        Clock c = new SystemClock();
        (cast(Object) c).toString();

 When is a "Clock" not an "Object"?

When it's derived from IUnknown, a special case put in to support COM interfaces on Win32. I've not heard anyone voice support for this particular design decision. I suppose it's very convenient if you happen to be a COM programmer, but I'm not sure why a vendor-specific technology like COM should get such special treatment in a language spec. --bb
Oct 01 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Bill Baxter escribió:
 On Thu, Oct 2, 2008 at 5:59 AM, Thomas Leonard <talex5+d gmail.com> wrote:
 Hi,

 I'm used to interfaces in Java, and I'm wondering why this doesn't work
 in D:

  interface Clock {}

  class SystemClock : Clock {}

  void main(string[] args) {
        Clock c = new SystemClock();
        c.toString();
  }

 It says:

  $ dmd clock.d
  clock.d(7): Error: no property 'toString' for type 'clock.Clock'

 This compiles, though:

        Clock c = new SystemClock();
        (cast(Object) c).toString();

 When is a "Clock" not an "Object"?

When it's derived from IUnknown, a special case put in to support COM interfaces on Win32. I've not heard anyone voice support for this particular design decision. I suppose it's very convenient if you happen to be a COM programmer, but I'm not sure why a vendor-specific technology like COM should get such special treatment in a language spec. --bb

Better support a mostly unused specific case, than the broader general case, right? :-(
Oct 01 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Ary Borenszweig wrote:
 Bill Baxter escribió:
 On Thu, Oct 2, 2008 at 5:59 AM, Thomas Leonard <talex5+d gmail.com> 
 wrote:
 Hi,

 I'm used to interfaces in Java, and I'm wondering why this doesn't work
 in D:

  interface Clock {}

  class SystemClock : Clock {}

  void main(string[] args) {
        Clock c = new SystemClock();
        c.toString();
  }

 It says:

  $ dmd clock.d
  clock.d(7): Error: no property 'toString' for type 'clock.Clock'

 This compiles, though:

        Clock c = new SystemClock();
        (cast(Object) c).toString();

 When is a "Clock" not an "Object"?

When it's derived from IUnknown, a special case put in to support COM interfaces on Win32. I've not heard anyone voice support for this particular design decision. I suppose it's very convenient if you happen to be a COM programmer, but I'm not sure why a vendor-specific technology like COM should get such special treatment in a language spec. --bb

Better support a mostly unused specific case, than the broader general case, right? :-(

I've seen a number of issues relating to this -- for instance, tango's Variant had issues with inserting something as an interface and retrieving it as the class: interface IFoo {} class Foo : IFoo {} Variant v = cast(IFoo)new Foo; variant.get!(Foo); // throws VariantTypeMismatchException This was resolved, fortunately, but people will encounter problems relating to this indefinitely.
Oct 01 2008
prev sibling parent Bryan Power <bp2626 yahoo.com> writes:
Bill Baxter wrote:
 
 When it's derived from IUnknown, a special case put in to support COM
 interfaces on Win32.
 I've not heard anyone voice support for this particular design decision.
 I suppose it's very convenient if you happen to be a COM programmer,
 but I'm not sure why a vendor-specific technology like COM should get
 such special treatment in a language spec.
 
 --bb

Steven Schveighoffer wrote:
 The issue is totally with COM.
 
 Without the requirement for any interface to possibly be a COM interface, 
 all interfaces would implicitly inherit from ObjectInterface or some 
 interface that always has the functions required in Object defined (e.g. 
 toString()).
 

interfaces have no required base functions. Making life difficult for those who never ever work with COM (and I can't say I blame them, COM sucks). -Steve

A fair bit of extended API functionality on Windows is presented via COM. This includes very important API sets like DirectX, which is implemented via COM. A bonus of COM is that it allows use of the API in its OOP form in C++ while still allowing the API to be used in procedural languages like IA32, C and Pascal without any hacks or tricks. Even Mozilla has their own COM implementation. While I admit COM can be messy at times, I use it almost daily for my work, and since I am free to use the languages of my choosing I generally use D. This interface feature allows me to port COM definitions from the C/C++ headers to D seamlessly and quickly: interface IWbemObjectSink : IUnknown {} for example. I am all for the COM compatibility.
Oct 02 2008
prev sibling next sibling parent reply ylixir <ylixir gmail.com> writes:
Thomas Leonard wrote:
 Hi,
 
 I'm used to interfaces in Java, and I'm wondering why this doesn't work 
 in D:
 
   interface Clock {}
 
   class SystemClock : Clock {}
 
   void main(string[] args) {
 	Clock c = new SystemClock();
 	c.toString();
   }
 
 It says:
 
   $ dmd clock.d
   clock.d(7): Error: no property 'toString' for type 'clock.Clock'
 
 This compiles, though:
 
 	Clock c = new SystemClock();
 	(cast(Object) c).toString();
 
 When is a "Clock" not an "Object"?
 
 Thanks,

"Clock" is never an "Object". Object is a class every other class is implicitly inherited from, and interfaces cannot be derived from classes, otherwise you would wind up with the nastiness that makes multiple inheritance in c++ such a nightmare (diamond shaped inheritance trees, etc), and would in fact eliminate the need for interfaces altogether. casting c to Object works because SystemClock inherits from Object, without the cast it doesn't work because Clock is not inherited from Object. Maybe i'm missing something, as others seem to be going on about COM programming, but i don't think this has anything to do with COM, it's simply that D doesn't support multiple inheritance, with good reason.
Oct 02 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"ylixir" wrote
 Thomas Leonard wrote:
 Hi,

 I'm used to interfaces in Java, and I'm wondering why this doesn't work 
 in D:

   interface Clock {}

   class SystemClock : Clock {}

   void main(string[] args) {
 Clock c = new SystemClock();
 c.toString();
   }

 It says:

   $ dmd clock.d
   clock.d(7): Error: no property 'toString' for type 'clock.Clock'

 This compiles, though:

 Clock c = new SystemClock();
 (cast(Object) c).toString();

 When is a "Clock" not an "Object"?

 Thanks,

"Clock" is never an "Object". Object is a class every other class is implicitly inherited from, and interfaces cannot be derived from classes, otherwise you would wind up with the nastiness that makes multiple inheritance in c++ such a nightmare (diamond shaped inheritance trees, etc), and would in fact eliminate the need for interfaces altogether. casting c to Object works because SystemClock inherits from Object, without the cast it doesn't work because Clock is not inherited from Object. Maybe i'm missing something, as others seem to be going on about COM programming, but i don't think this has anything to do with COM, it's simply that D doesn't support multiple inheritance, with good reason.

The issue is totally with COM. Without the requirement for any interface to possibly be a COM interface, all interfaces would implicitly inherit from ObjectInterface or some interface that always has the functions required in Object defined (e.g. toString()). But COM objects don't have the same base functions as Object does, so interfaces have no required base functions. Making life difficult for those who never ever work with COM (and I can't say I blame them, COM sucks). -Steve
Oct 02 2008
prev sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
ylixir wrote:
 Thomas Leonard wrote:
 Hi,

 I'm used to interfaces in Java, and I'm wondering why this doesn't 
 work in D:

   interface Clock {}

   class SystemClock : Clock {}

   void main(string[] args) {
     Clock c = new SystemClock();
     c.toString();
   }

 It says:

   $ dmd clock.d
   clock.d(7): Error: no property 'toString' for type 'clock.Clock'

 This compiles, though:

     Clock c = new SystemClock();
     (cast(Object) c).toString();

 When is a "Clock" not an "Object"?

 Thanks,

"Clock" is never an "Object". Object is a class every other class is implicitly inherited from, and interfaces cannot be derived from classes, otherwise you would wind up with the nastiness that makes multiple inheritance in c++ such a nightmare (diamond shaped inheritance trees, etc), and would in fact eliminate the need for interfaces altogether. casting c to Object works because SystemClock inherits from Object, without the cast it doesn't work because Clock is not inherited from Object. Maybe i'm missing something, as others seem to be going on about COM programming, but i don't think this has anything to do with COM, it's simply that D doesn't support multiple inheritance, with good reason.

In Java you can implicitly cast an interface to an Object. This is also true in C#. Why? Because an interface is nothing by itself. An interface can only exist in runtime in the form of a class that implements it. Now you know that every class has Object as a top superclass. Since you can cast any class to Object, and since an interface can only exist in runtime in the form of a class, you can impllicity convert any interface to an Object. This doesn't work in D because there's an interface named IUnknown used to do COM stuff, and classes that implement that interface don't have Object as the top superclass. Tihs breaks my previous "demonostration" (every class has Object as a top superclass).
Oct 02 2008
prev sibling next sibling parent Thomas Leonard <talex5+d gmail.com> writes:
On Thu, 02 Oct 2008 06:12:26 +0900, Bill Baxter wrote:

 On Thu, Oct 2, 2008 at 5:59 AM, Thomas Leonard <talex5+d gmail.com>
 wrote:
 Hi,

 I'm used to interfaces in Java, and I'm wondering why this doesn't work
 in D:

  interface Clock {}

  class SystemClock : Clock {}

  void main(string[] args) {
        Clock c = new SystemClock();
        c.toString();
  }

 It says:

  $ dmd clock.d
  clock.d(7): Error: no property 'toString' for type 'clock.Clock'


 When is a "Clock" not an "Object"?

When it's derived from IUnknown, a special case put in to support COM interfaces on Win32. I've not heard anyone voice support for this particular design decision. I suppose it's very convenient if you happen to be a COM programmer, but I'm not sure why a vendor-specific technology like COM should get such special treatment in a language spec.

Ah, I see. I'm not too worried about COM support, so I edited mtype.c to return MATCHconvert whenever the target is Object. That fixes it for me: http://repo.or.cz/w/delight/core.git?a=commit;h=4e5750a980ef24b65284342f51f549a9d23dc282 Thanks!
Oct 02 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Oct 2, 2008 at 7:36 PM, Bryan Power <bp2626 yahoo.com> wrote:
 Bill Baxter wrote:
 When it's derived from IUnknown, a special case put in to support COM
 interfaces on Win32.
 I've not heard anyone voice support for this particular design decision.
 I suppose it's very convenient if you happen to be a COM programmer,
 but I'm not sure why a vendor-specific technology like COM should get
 such special treatment in a language spec.

 --bb

Steven Schveighoffer wrote:
 The issue is totally with COM.

 Without the requirement for any interface to possibly be a COM interface,
 all interfaces would implicitly inherit from ObjectInterface or some
 interface that always has the functions required in Object defined (e.g.
 toString()).

interfaces have no required base functions. Making life difficult for those who never ever work with COM (and I can't say I blame them, COM sucks). -Steve

A fair bit of extended API functionality on Windows is presented via COM. This includes very important API sets like DirectX, which is implemented via COM. A bonus of COM is that it allows use of the API in its OOP form in C++ while still allowing the API to be used in procedural languages like IA32, C and Pascal without any hacks or tricks. Even Mozilla has their own COM implementation. While I admit COM can be messy at times, I use it almost daily for my work, and since I am free to use the languages of my choosing I generally use D. This interface feature allows me to port COM definitions from the C/C++ headers to D seamlessly and quickly: interface IWbemObjectSink : IUnknown {} for example. I am all for the COM compatibility.

I am as well, but treating it as the general case makes no sense. IUnknown and anything derived from it should be treated as special cases; anything else should be implicitly castable to Object.
Oct 02 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 3, 2008 at 8:42 AM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:
 On Thu, Oct 2, 2008 at 7:36 PM, Bryan Power <bp2626 yahoo.com> wrote:
 Bill Baxter wrote:
 When it's derived from IUnknown, a special case put in to support COM
 interfaces on Win32.
 I've not heard anyone voice support for this particular design decision.
 I suppose it's very convenient if you happen to be a COM programmer,
 but I'm not sure why a vendor-specific technology like COM should get
 such special treatment in a language spec.

 --bb

Steven Schveighoffer wrote:
 The issue is totally with COM.

 Without the requirement for any interface to possibly be a COM interface,
 all interfaces would implicitly inherit from ObjectInterface or some
 interface that always has the functions required in Object defined (e.g.
 toString()).

interfaces have no required base functions. Making life difficult for those who never ever work with COM (and I can't say I blame them, COM sucks). -Steve

A fair bit of extended API functionality on Windows is presented via COM. This includes very important API sets like DirectX, which is implemented via COM. A bonus of COM is that it allows use of the API in its OOP form in C++ while still allowing the API to be used in procedural languages like IA32, C and Pascal without any hacks or tricks. Even Mozilla has their own COM implementation. While I admit COM can be messy at times, I use it almost daily for my work, and since I am free to use the languages of my choosing I generally use D. This interface feature allows me to port COM definitions from the C/C++ headers to D seamlessly and quickly: interface IWbemObjectSink : IUnknown {} for example. I am all for the COM compatibility.

I am as well, but treating it as the general case makes no sense. IUnknown and anything derived from it should be treated as special cases; anything else should be implicitly castable to Object.

Same here. I have nothing against support for COM, just support for COM that complicates the common case for everyone just for the benefit of being able to use COM. I don't think such a compromise is required. But I also don't have an alternate design I can provide. I suspect that along the lines of what Ja-double-r-e-double-t says, there could be a foreign_interface type in D that objects can derive from. IUnknown could be one such foreign_interface. But that may just be making a bad situation worse. I'm pretty sure from looking at the DirectX headers that you can do COM in C++ without any fancy compiler support, so it seems likely that there could be a completely different approach to supporting COM (and other things) in a more general way via mixins and (someday) macros. Or maybe some new compile-time decorator syntax. --bb
Oct 02 2008