www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Non-fragile ABI in D?

reply Michel Fortin <michel.fortin michelf.com> writes:
http://michelf.com/weblog/2009/non-fragile-abi-in-d/

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 05 2009
next sibling parent reply grauzone <none example.net> writes:
Michel Fortin wrote:
 http://michelf.com/weblog/2009/non-fragile-abi-in-d/
 

Summary of the upcoming discussion: "use interfaces!" You should preemptively list reasons, why this is not enough.
Feb 05 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-05 08:51:39 -0500, grauzone <none example.net> said:

 Summary of the upcoming discussion: "use interfaces!"
 
 You should preemptively list reasons, why this is not enough.

Well, you can't create a subclass and override functions if only the interface is exposed. In fact, exposing only interface offers little more than exposing static functions wrapping calls to member functions. And with static functions you can insert one in the middle with no side-effect. Sure, there's always a way to make things work with interfaces, just like you can do everything in C if you want, or you can force everyone to recompile each time they update their libs. In all cases, it's not very impressive that an object-oriented ABI is so fragile in an object-oriented language. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 05 2009
prev sibling parent reply BCS <ao pathlink.com> writes:
Reply to Michel,

 http://michelf.com/weblog/2009/non-fragile-abi-in-d/
 

What I would like to see is the vtbl offsets being patched up by the linker. That way the vtbl can be reordered with impunity and you only need to re link. You still can't get binary compatibility for DLL/SO's (unless loading them does patching as well?)
Feb 05 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-05 12:53:07 -0500, BCS <ao pathlink.com> said:

 What I would like to see is the vtbl offsets being patched up by the 
 linker. That way the vtbl can be reordered with impunity and you only 
 need to re link. You still can't get binary compatibility for DLL/SO's 
 (unless loading them does patching as well?)

There are many options. Either it's done by the linker and the dynamic library loader, or it's done by the library initialization code, or lazily on the first use of a class. Or we don't use virtual function tables at all... -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 There are many options. Either it's done by the linker and the dynamic 
 library loader, or it's done by the library initialization code, or 
 lazily on the first use of a class. Or we don't use virtual function 
 tables at all...

As one wag put it, the solution to all problems is another level of indirection. This can work here, too. Have your only field in a class be a reference to an opaque type, and a member function that is a dispatcher based on a string argument or such. The implementation of the member function dispatches to the actual class being opaquely referenced and the string value. This is all completely hidden from the user, so it can be arbitrarily extended without the user needing to recompile. In dynamic languages, this is what happens anyway under the hood. It's how javascript works, for example. The downside is it's quite a bit slower.
Feb 08 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-08 05:41:11 -0500, Walter Bright <newshound1 digitalmars.com> said:

 As one wag put it, the solution to all problems is another level of 
 indirection. This can work here, too. Have your only field in a class 
 be a reference to an opaque type, and a member function that is a 
 dispatcher based on a string argument or such.
 
 The implementation of the member function dispatches to the actual 
 class being opaquely referenced and the string value. This is all 
 completely hidden from the user, so it can be arbitrarily extended 
 without the user needing to recompile.

That's an interesting solution. But you're only solving half of the initial problem: the library author may want to extend his class to provide new override points. That's not really possible in your proposed solution, as it'd change the vtable of the exposed class. And of course, it's always possible to come with a scheme that will work. But then you'd be inventing a new meta-language inside D, using special dispatch functions and a special override syntax, all this for working around the fragility of the D class ABI. The solution is worse than the initial problem: for ABI stability you're trading clarity in the API, something that diminish greately the interest of having an object-oriented API. I'm not trying to convince you to add an Objective-C-like dispatch mecanism in D, I'm trying to convince you that there is a need, and that it can only be satisfied adequately by the language. An idea would be to build the vtables at runtime and update the offsets in the code after loading or use global variables to store vtable offsets. This way, the ABI is less fragile and you can still keep the speed advantage over Objective-C and other dynamic languages. But if you don't recognize there is a need, it'll be hard to convince you to implement something for filling it.
 In dynamic languages, this is what happens anyway under the hood. It's 
 how javascript works, for example.
 
 The downside is it's quite a bit slower.

Indeed, it's slower. But in JavaScript and many other dynamic languages, you don't have the choice to use dynamic dispatch for everything because that's all they have. Compare to D, where when you need performace you already avoid using classes and prefer structs, static functions, and templates. That's of course not an excuse to make classes less performant. But it may be a hint that performance is a little less important for classes, giving us an opportunity to improve the design and make them more robust and useful. Oh, and I'm glad you replied by the way. :-) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 08 2009