www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: A renewed call for interface methods with bodies

reply Burton Radons <burton-radons shaw.ca> writes:
BCS Wrote:

 Ary Borenszweig wrote:
 Burton Radons escribió:
 
 BCS Wrote:

 Burton Radons wrote:
 [...]


 something just occurred to me:

 The only actions that a function body in an interfaces could do to 
 "this" is function calls that would have to be virtual (or how could 
 it ever do anything) however the code generated for a interface 
 method needs to know the type of the object to be able to make the 
 calls correctly. The only reasonable way I can see to let interface 
 functions have bodies would be to in effect use a mixin.

 Can anyone think of a better solution?

There aren't any problems in compiling interface methods with bodies - it's exactly the same as a class with abstract methods.

Doesn't that lead to multiple inheritance, with all its complexities?

I think it would be more complex than the current implementation but not that complex.

It would be simpler. Classes and interfaces are implemented almost identically in DMD. There are simply some checks that prevent interface methods from having bodies. This is not supposition - keep in mind that I ported DMD to Linux six years ago (http://www.opend.org/dli/DLinux.html). There may be some code generation bugs, but they wouldn't be hard to squash.
 The issue is that with the current interfaces, the function pointers in 
 the interface v-tbl are specific to the class that implements the 
 interfaces. This results in the code expecting the this pointer to point 
 to the start of the object where the class v-tbl is (or there abouts). 
 For the proposed interfaces to work simply, the this pointer inside the 
 un-overloaded function would have to point to the interface v-tbl (which 
 IIRC is not at the start of the object, but inside overloaded functions, 
 it would have to point the the start of the object. I can't think of any 
 simple way to make this work.

Actually, this is the same as it is now: when you call a method that implements an interface, it receives as the "this" pointer the interface, not the object (otherwise you wouldn't be able to implement COM interfaces in D). I can't recall if the compiler converts it into an object in the method or in a trampoline in the interface's vtable. I asked Walter at the time as I was having trouble getting interfaces to work in DLI, but I can't recall the answer.
 I'll grant it can work, I expect it would be somewhat complex though.

Jan 27 2008
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Sun, 27 Jan 2008 19:35:02 -0500, Burton Radons wrote:

 BCS Wrote:
 
 Ary Borenszweig wrote:
 Doesn't that lead to multiple inheritance, with all its complexities?

I think it would be more complex than the current implementation but not that complex.

It would be simpler. Classes and interfaces are implemented almost identically in DMD. There are simply some checks that prevent interface methods from having bodies. This is not supposition - keep in mind that I ported DMD to Linux six years ago (http://www.opend.org/dli/DLinux.html). There may be some code generation bugs, but they wouldn't be hard to squash.

I don't think anyone is arguing whether it would be possible to implement or not. The reason there are checks added to interfaces is because you can inherit from more than one interface, but classes have an added check to prevent that.
Jan 28 2008