Daniel Keep wrote:
grauzone wrote:
Nick Sabalausky wrote:
[snip]
Umm, go into class A and add whatever you need?
Maybe I can't, because it's foreign code. Changing it might increase
maintenance overhead, require recompilation of libraries, might
introduce additional module dependencies, which in the worst case lead
to cyclic dependencies or dependencies from a library into the
application, and so on.
I've heard this argument before, and it's always confused me. How are
you going to expand a class that you don't have (or have, but don't want
to change) the source of?
You say that as if this was impossible. In the most primitive way, you'd
do something like ClassInfo.init.length += 1 to extend a class by one
byte and use the old length as offset to your own data. Of course, in
reality, it's not that simple.
By the way, AspectJ can do this at link time, and all dynamic languages
at runtime.
Your foreign library will create instances at a certain size, with a
certain vtable, etc. The only way I can see that you could change the
instantiated objects would be to subvert it's object creation code. But
how are you going to do that when the library has already been compiled?
The object creation code could call a library routine, which checks the
other modules linked to the program? Again, it's not that hard to come
up with a naive approach.
You could put all the ctors into a shared module somewhere, but at that
point you no longer need partial classes, since you can simply replace
the class with an entirely different one like, say, a subclass.
And if your library doesn't create instances, then you can just use
inheritance straight up.
The point of this approach is to avoid all this.
There's the argument that it lets you add functionality to a class you
use but don't manage yourself, but generalised function syntax (a(b,...)
-> b.a(...)) takes care of that for everything.
Lacks virtual methods.
The only argument I've ever seen that held water was to separate the
implementation of a class among multiple files. But we have template
mixins to do that.
Template mixins are a horrible thing to do this. Even using
mixin(import("include.inc")) causes less problems.
(By the way, maybe D should abandon the module principle and compile
several D source files at once to an "assembly". Then distributing a
class implementation over several source files would be as simple as in
C#. Maybe this also would fix all of the circular module dependency bugs
by not allowing circular dependencies as compilation units.)
I'm not saying it wouldn't be useful, I just can't see any legitimate
reason for it that is either technically possible, or that you can't
already fulfil some other way.
-- Daniel
