std.mixins

[Jacob Carlborg]

On 2010-08-31 05:49, dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> On 8/30/10 20:04 PDT, dsimcha wrote:
>>> I've been toying for a long time with the idea of a std.mixins for Phobos that
>>> would contain meta-implementations of commonly needed boilerplate code for
>>> mixing into classes and and structs.  I've started to prototype it
>>> (http://dsource.org/projects/scrapple/browser/trunk/std_mixins/std_mixins.d).
>>>    So far I have a mixin for struct comparisons, which is useful if you need a
>>> total ordering for use with sorting or binary trees, but don't care exactly
>>> how that ordering is defined.  I've also got a mixin that converts a class to
>>> a Singleton, and uses thread-safe but efficient mechanisms to deal with the
>>> __gshared singleton case.
>>>
>>> I'm also thinking of creating some mixins to allow cloning of arbitrarily
>>> complicated object graphs, provided that you don't stray outside of SafeD.  Is
>>> this worth implementing or will it likely be solved in some other way at some
>>> point?
>>>
>>> Right now I'd just like to milk the D community for ideas.  What other pieces
>>> of boilerplate code do you find yourself writing often that the standard
>>> library should help with?
>> Sounds like a good idea, but I think the name is not too descriptive as
>> it refers to mechanism. We shouldn't have std.classes or std.structs in
>> there, should we? :o) Therefore std.mixins sounds like an awkward way to
>> group together pieces of functionality that may be very diverse.
>> FWIW I think you don't need any mixins to implement cloning. But I do
>> encourage you to work on cloning - I wanted for the longest time and
>> couldn't get to it. A cloning routine would need to keep a map of
>> pointer to pointer to make sure in only clones each object in a graph once.
>> Andrei
>
> I had an almost working implementation of cloning that didn't depend on mixins a
> long time (like 2 years) ago.  It didn't work with raw pointers to non-primitive
> data (supporting this would, of course, be impossible) or where polymorphism was
> involved.
>
> The big problem with cloning is derived classes.  Give a class reference whose
> compile time type is Base, but whose runtime type is Derived, how do you clone the
> derived fields w/o some boilerplate code either being written, mixed in, or
> generated by the compiler?   Keep in mind that D's compilation model prevents you
> from being able to get a tuple of all derived classes of a base class at compile
> time.  Actually, IIRC you were the one who explained this to me back when I first
> tried to make cloning work and asked how to get such a tuple.

Exactly, this is not currently possible in D without having to implement 
an extra function doing the cloning, I had the same problem implementing 
my serialization library Orange (http://dsource.org/projects/orange/). 
Actually a serialization library could be used to implement cloning, 
seem my reply to Andrei: 
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=116518

-- 
/Jacob Carlborg