On 06/25/2012 11:26 PM, Manu wrote:
On 25 June 2012 23:30, Walter Bright <[email protected]
<mailto:[email protected]>> 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.
