Orange - Free from D1/Tango

[Steven Schveighoffer]

On Mon, 18 Feb 2013 18:43:16 -0500, qznc <qznc at go.to> wrote:

> 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)?

Most likely a mutex is a core library feature, and we can mark it as not  
serializeable.  If (when?) phobos gets serialization, I would expect the  
core types to be marked as such.

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

For D, we have shared which indicates it may be viewed by more than one  
thread.  Shared data could be opt-in for serialization.

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

I would expect that something that complex has to be specifically written  
to deal with serialization.

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

Just because someone is stupid and tries to serialize a non-serializable  
construct such as a gui toolkit, it's not the serializer's fault.

I don't think opt-in is stupid, it's just a more conservative set of  
rules.  I think the number of constructs that WON'T be serializable will  
be far less than the ones that will be.

And multi-thread access items could be made opt-in.  I'm not sure what  
Orange does now.

-Steve