Request for pre-review: std.serialization/orange

[Jacob Carlborg]

On 2011-09-30 15:03, Robert Jacques wrote:
> On Thu, 29 Sep 2011 14:58:30 -0400, Jacob Carlborg <doob at me.com> wrote:
>> I would like to have some form of pre-review of my serialization library
>> Orange for later inclusion in Phobos as std.serialization (or similar).
>
> [snip]
>
> This is a quick note on the API design; I'm planning on doing a deeper
> review of the code + API later.
>
> Re: registerSerializer
> Type.stringof is not unique and can't be used by your serializer.

I don't know why but I thought Type.stringof == typeid(Type).toString 
for everything that wasn't a class.

> Furthermore, allowing users to manually set the lookup string is going
> to be a major source of silent errors / bugs and exposes a large
> portions of your internals. Doing it in this way prevents you from
> updating how the back-end looks up types.
>
> I'd recommend using: typeid(A).toString internally instead as this is
> unique and registerSerializer's API to
>
> void registerSerializer(Derived,Base)(void delegate(Base) dg) if(
> is(Derived:Base) ) {}
>
> which would be called via:
>
> registerSerializer!Foo(dg);

Didn't thought of that, thanks.

> The method should also be static: If I'm registering a custom
> serialization method, I don't want to duplicate that mapping everywhere
> a serializer is instanced. I don't even want to duplicate it for every
> type of serializer. I think there needs to be some granularity for this:
> i.e. instance -> type -> global.

"register" is static, "registerSerializer" is not because I'm not 
entirely sure how I want the API to behave.

What if I want to serialize a class in two different places. In one 
place I want to serialize it by default and in the other I want to do 
custom serialization?

"I don't even want to duplicate it for every type of serializer". I'm 
not sure I quite understand, there's only one type of serializer.

> Also, repeat the above for registerDeserializer.
>
>
> Re: deserialize some of the example don't look like they're correct.

They look correct to me. Note that two of the three "deserialize" 
methods should only be called when performing custom deserialization of 
a class/strut. This method will then, most likely, be called from within 
the class to manually deserialize the fields.

-- 
/Jacob Carlborg