Partial classes

[Manu]

On 25 June 2012 23:30, Walter Bright <newshound2 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120626/b4d03432/attachment-0001.html>