std.mixins

[Denis Koroskin]

On Tue, 31 Aug 2010 19:13:17 +0400, Jacob Carlborg <doob at me.com> wrote:

> On 2010-08-31 05:17, Andrei Alexandrescu wrote:
>> 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
>
> My serialization library Orange (http://dsource.org/projects/orange/)  
> could be used for cloning. The easiest way to do this is just to  
> serialize a value and then deserialize the data and return the new  
> value. Of course this wouldn't be the most efficient way, for that one  
> could build a cloning library/function out of the front end of the  
> serializer.
>

A generic clone function is a very interesting idea, it is also a safe way  
of creating immutable copies of mutable data structures (assumeUnique is  
great but a dangerous one to use).

Now that we talk about serializing, I wrote a serialization library of my  
own, too :) Unlike yours, it uses binary serialization, though.

What it does is what a Moving GC would do, i.e. compacting objects to use  
less memory, so de-serialization is done at constant time (unless you need  
to adjust pointers) and it's also happen to be the most efficient way to  
object cloning.

I believe binary serialization is the most suitable solution for passing  
data structures of any complexity between threads, over network or loading  
resources from disk due to its performance and low memory usage. It also  
improves data locality, so just cloning your data may lead to a  
significant speedup in data processing and reduced memory usage.