Request for pre-review: std.serialization/orange

[Jacob Carlborg]

On 2011-10-04 17:14, Robert Jacques wrote:
> I'm sorry, you're right. In my mind b extended to the end of the a
> array, for some reason. However, if you do define b to extend to the end
> of the a array, then it can append without allocating:
>
> auto a = [0, 1, 2, 3, 4];
> auto b = a[2 .. $];
> b ~= 5;
> assert(b[0]==2);
> a[2] = 10;
> assert(b[0]==10);
>
> So please don't dismiss this point.
>

Hmm, D1 and D2 behaves differently in this case. In D1 "a" is not 
changed when "b" is changed. Since you append to "b" I though that it 
would always require a reallocation of "b".

> [snip]
>
>> Would this something similar to:
>> https://github.com/jacob-carlborg/orange/blob/master/orange/serialization/Serializer.d#L1520
>>
>> ?
>
> I'm not sure, that routine seems to be filtering pointers between those
> with aliases and those without aliases, which would be similar in effect
> to:
>
> if( auto node = arr.ptr in setOfAliases ) {} else {}
>
>> What is the advantage with using a tree? Is the advantage that you loop
>> over the elements once in the pseudo-code compared to that I loop over
>> them twice, as in:
>> https://github.com/jacob-carlborg/orange/blob/master/orange/serialization/Serializer.d#L1495
>>
>> ?
>
> Primarily, it's O(N logN) vs O(N^2). Also, it solves the isSliceOf
> problem we discussed above and puts arrays and objects into the same
> framework, as objects containing fixed sized arrays can have slices.

I guess I just have to try this and see how it works out. Anyway, thank 
you for your review and your patience.

-- 
/Jacob Carlborg