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
