Non-fragile ABI in D?

[Michel Fortin]

On 2009-02-08 05:41:11 -0500, Walter Bright <newshound1 at 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 at michelf.com
http://michelf.com/