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