On Sunday, 17 February 2013 at 21:52:53 UTC, Adam Wilson wrote:
> On Sun, 17 Feb 2013 13:18:05 -0800, Walter Bright <newshound2@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?
>>
>
> Every serialization library i've used is opt-out.

That doesn't mean it is the way.

I have to say I don't know if it is better to opt in or out, simply that most serialization framewrok I have used as of now weren't that great, and I'm sure we can do better with both compile time reflection and annotations.

On Sun, 17 Feb 2013 22:08:26 -0500, deadalnix <deadalnix@gmail.com> wrote:

> On Sunday, 17 February 2013 at 22:13:21 UTC, Steven Schveighoffer wrote:
>> On Sun, 17 Feb 2013 16:18:05 -0500, Walter Bright <newshound2@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?
>>
>> I would think D's type system would be capable enough where a serialization library can tell whether a type can be serialized or not.
>>
>
> It isn't as it don't convey ownership. And hopefully as getting rid of ownership is important for idioms involving immutability.

Right, but in that case, you may have a common reference serialized several times.  Not necessarily the end of the world.

Perhaps what we need is two things:

1. A UDA that indicates "this type is certified correct for serialization"
2. A flag to serializer somehow that indicates "only serialize types that are certified correct for serialization, and pure value types"

I would hate to (and have hated to) mark serializable types when it is a trivial type, just because it's used inside a serializable type.

-Steve

On 2/17/2013 1:43 PM, H. S. Teoh wrote:
> I believe the purpose of the library is to provide convenient saving /
> loading of objects (among other things), so you want most of your data
> serialized, and non-serialized fields are the exception rather than the
> norm.  So it makes sense to serialize by default and mark out fields
> that shouldn't be serialized.

I've done some work with serialization, and it was a minority of the data types that needed serialization.

On Sun, Feb 17, 2013 at 07:22:03PM -0800, Walter Bright wrote:
> On 2/17/2013 1:43 PM, H. S. Teoh wrote:
> >I believe the purpose of the library is to provide convenient saving / loading of objects (among other things), so you want most of your data serialized, and non-serialized fields are the exception rather than the norm.  So it makes sense to serialize by default and mark out fields that shouldn't be serialized.
> 
> I've done some work with serialization, and it was a minority of the data types that needed serialization.

Wait, I thought the whole point was that the user code specifically asks for the serialization of a particular data structure, so presumeably most of the objects recursively referenced by that object will tend to be data objects where the vast majority of fields should be serialized.

I don't think the point was to blindly serialize every object in the program?


T

-- 
If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell

On Monday, 18 February 2013 at 03:22:07 UTC, Steven Schveighoffer wrote:
> Right, but in that case, you may have a common reference serialized several times.  Not necessarily the end of the world.
>

This is a problem as D promote the concept of identity in addition to value.

On 2013-02-17 22:43, H. S. Teoh wrote:

> I believe the purpose of the library is to provide convenient saving /
> loading of objects (among other things), so you want most of your data
> serialized, and non-serialized fields are the exception rather than the
> norm.  So it makes sense to serialize by default and mark out fields
> that shouldn't be serialized.

Exactly, Orange has had this behavior from day one.

-- 
/Jacob Carlborg

On 2013-02-17 22:52, Adam Wilson wrote:

> Every serialization library i've used is opt-out.

Java - Requires annotation
Ruby - Doesn't require anything

-- 
/Jacob Carlborg

> I would think D's type system would be capable enough where a
> serialization library can tell whether a type can be serialized or not.

Sometimes you don't want to serialize a field, regardless if the serialization library can serialize it or not. This will require a manual annotation.

> I also think it would be a tremendous burden to put @serialized on every
> type that could be serialized.
>
> When I used C#'s serializer, it was definitely annoying to have to
> annotate every type I wanted to serialize, and every type that was used
> within that type.
>
> What is the concern with an opt-out approach?  I would think the default
> would be the most common option -- save everything.

I agree.

-- 
/Jacob Carlborg

On 2013-02-18 04:22, Steven Schveighoffer wrote:

> Right, but in that case, you may have a common reference serialized
> several times.  Not necessarily the end of the world.

No reference type should be serialized more than once. If it is, it's bug.

> Perhaps what we need is two things:
>
> 1. A UDA that indicates "this type is certified correct for serialization"
> 2. A flag to serializer somehow that indicates "only serialize types
> that are certified correct for serialization, and pure value types"

Hmm, I'm wondering if that's getting too complex.

> I would hate to (and have hated to) mark serializable types when it is a
> trivial type, just because it's used inside a serializable type.

Me too.

-- 
/Jacob Carlborg

On 2013-02-18 02:27, Steven Schveighoffer wrote:

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

-- 
/Jacob Carlborg