On 25 June 2012 23:30, Walter Bright <newshound2@digitalmars.com> wrote:
On 6/25/2012 8:26 AM, Manu wrote:
I suspect this isn't possible in a compiled language like D, but I wonder
anyway, has anyone considered partial classes in D? Are they technically possible?
How would they work? Would it depend on link-time code generation?
I can imagine an implementation where each 'part' occupies a separate
allocation, and some pointer in Object or somewhere like that (somewhere near
the typeinfo pointer) binds them together.
Are you talking about adding fields/functions to an arbitrary class without modifying the original definition of that class?
If so, this would violate principles of encapsulation, and there'd be terrible consequences (as you could not rely on the class definition being the class definition without examining the entire code base).
But this is essentially no different than UFCS, except to me it feels like less of a hack than UFCS (which I personally find rather dirty by contrast). Additionally, often enough, that UFCS function depend on adding a piece of data to the object in addition to the functionality it implements.
I don't think it's fair to say it would lead to terrible consequences, because it exists, and it's used very successfully in other languages. It's proven to be very useful.
I have a recurring problem where, at the module level, using CTFE I can scan the module for information, and generate bindings of things to their related systems without lots of manual, messy, error-prone hook-up code.
For me, I think this has been the single biggest advantage I've gotten from using D yet hands down.
The problem is, it's limited to things in the global scope. Partial classes are the completion of that concept, allowing it to be applied to classes too.
If when scanning a class I find it has relationships to given systems, I can't then magically add the appropriate binding to that system into the class. There are some fairly messy hack-arounds that kinda work, but they don't very very tight, not like in C# for instance anyway.
If it's not added to the class its self, all of the IDE features that I am always claiming are so critical don't really work. The self-documenting, self-writing, auto-completion, popup member/parameter helpers and stuff don't work.
Also, quite to the contrary of what you say, separating the functionality that should be embedded in the class from the class, it breaks the encapsulation principle. The class should gain that property internally, not bolted on the side with some hacky mechanisms.
But, you can use UFCS to "add" member functions to an existing class.
Indeed, but it's not quite the same.
Adding data members can be done using the PIMPL technique, string mixins, or template mixins (but the original class needs to be designed for that).
And that's basically the limitation I'd like to overcome. The fact something needs to be designed for it in advance; that is completely unrealistic.
No 3rd party can ever anticipate what you might want to do. Whether you want to unintrusively extend some existing code, or you provide a library which can extend things in a general way.. If you can craft your partial extension in such a way than it integrates neatly with the 3rd party stuff you're using, that seems like a much more sensible approach, since it leaves the customisation to you, rather than the original author to attempt to anticipate...
I really hate it when I have to butcher 3rd party code to add my bits. It makes it hard to maintain, if the author updates the code. Much nicer to extend it with my bit as a partial, and keep my code clinically separated.