Orange - Free from D1/Tango

[qznc]

On Monday, 18 February 2013 at 01:27:17 UTC, Steven Schveighoffer 
wrote:
> On Sun, 17 Feb 2013 19:58:06 -0500, Nick Sabalausky 
> <SeeWebsiteToContactMe at semitwist.com> wrote:
>
>> On Sun, 17 Feb 2013 13:18:05 -0800
>> Walter Bright <newshound2 at digitalmars.com> wrote:
>>
>>> On 2/17/2013 12:51 PM, Jacob Carlborg wrote:
>>> > I just stripped out all D1 and Tango related code from 
>>> > Orange.
>>> > D1/Tango is still supported in the d1 branch. Hopefully 
>>> > this will
>>> > make it easier to integrate into Phobos.
>>> >
>>> > It also now supports UDA's for indicating a 
>>> > field/class/struct
>>> > shouldn't be serialized:
>>> >
>>> > class Foo
>>> > {
>>> >     @nonSerialized int a;
>>> > }
>>> >
>>> > @nonSerialized class Bar { }
>>>
>>> Hmm, shouldn't it be the other way around - marking the ones 
>>> to be
>>> serialized?
>>>
>>
>> You're already opting-in to serialization anyway when you say
>> "serialize object foobar". @serializable would just be 
>> redundant.
>>
>
> I think Walter's point is that the author of foobar may not 
> have opted in.
>
> My response to that is, so?  If someone is trying to serialize 
> your class, and you didn't test for that, too bad for that 
> person if it doesn't work.
>
> The reality is, an author may write foobar without intending it 
> to be serializable, but it actually is.  In that case, it is 
> still on the user, but if it works, great!  The user is taking 
> the risk that later the serialization breaks, and could always 
> submit a patch to the author of foobar if it somehow becomes 
> not-working in a future version.
>
> To have to say:
>
> struct S
> {
>   int x;
>   int y;
> }
>
> is serializable seems like super-redundant info.  The D type 
> system is one of the most advanced I've ever seen.  Let's try 
> and use it!

I agree that for lots of code it is redundant (data structures in 
general). It might even be desirable for library code, whose 
author did not consider Orange. However, it might lead into 
subtle bugs in some cases.

For example, what happens with a mutex? Would Orange serialize it 
with all its state (locked or unlocked)?

What happens with data structures, which are used in parallel. 
For a consistent serialization it might be necessary to take a 
lock first. In this case, the data structure must be able to 
provide its own serialization method.

I have not seen a "skip on serialize, but re-initialize on 
deserialize" annotation, which would be the correct behavior for 
uncontested thread-safe data structures using locks.

The most complex case would probably be something like a GUI 
toolkit. If I serialize a GtkD app on Linux and deserialize it on 
Windows, will it be able to produce a working GUI? It must 
provide a custom deserialize method to do that.

Looking at all those edge cases, an opt-in approach seems not 
that stupid to me. It might be tedious to add all those 
@serializeable annotations, but at least you do not run into 
weird deadlocks.