std.mixins

[Jacob Carlborg]

On 2010-08-31 18:11, Denis Koroskin wrote:
> 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.

I have not looked at your serialization library but mine has a separate 
front end (the serializer) and back end (the archive). Currently the 
library only has an XML archive but it would be possible to implement a 
binary archive as well.

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

-- 
/Jacob Carlborg