D versus Objective C Comparison

[grauzone]

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