D versus Objective C Comparison

[Daniel Keep]

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?

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?

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.

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.

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.

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