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