Partial classes

[Timon Gehr]

On 06/25/2012 11:26 PM, Manu wrote:
> On 25 June 2012 23:30, Walter Bright <newshound2 at digitalmars.com
> <mailto: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).

UFCS is just syntax. There is nothing deep/hacky/dirty behind it.

> 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.
>

It is not fair to say it is not fair, because the interpretation he has
given as a premise does not exist successfully in other languages. ;)

> 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.

What mechanism do you use? You cannot add symbols to a module without 
having dedicated code in the module that does it. Why is the mechanism
insufficient for classes? How would partial classes change the
situation?

> 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.

It would be useful if you showed some pseudocode.

> 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.

If the compiler can resolve symbols, in principle, an IDE should be able 
to list them.

> 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.
>

It does not break the encapsulation principle. Embedded class
functionality weakens data encapsulation.


>     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.

public class ImACSharpClass{ }

How to extend this class without changing the code?

What I don't get yet is why adding 'partial' to the class definition is 
any better than adding 'import myadditionalfunctionality; mixin 
MyAdditionalFunctionality'. Is it about the separate compilation? Or is
this just too 'hacky'?

> 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.

You can always use aggregation or inheritance. An use case would be of 
help here.