18-Feb-2013 05:27, Steven Schveighoffer пишет:
> On Sun, 17 Feb 2013 19:58:06 -0500, Nick Sabalausky
> <SeeWebsiteToContactMe@semitwist.com> 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?
>>>
>>
>> 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!

Exactly.

Would be nice to be able to mark the whole structs as non-serializable though. And of course, to not have to import serialization library just to get the annotations.
>
> -Steve


-- 
Dmitry Olshansky

On 2013-02-18 10:43, Dmitry Olshansky wrote:

> Exactly.
>
> Would be nice to be able to mark the whole structs as non-serializable
> though. And of course, to not have to import serialization library just
> to get the annotations.

import orange.serialization.Serializable;

@nonSerialized class Bar { }

-- 
/Jacob Carlborg

18-Feb-2013 14:28, Jacob Carlborg пишет:
> On 2013-02-18 10:43, Dmitry Olshansky wrote:
>
>> Exactly.
>>
>> Would be nice to be able to mark the whole structs as non-serializable
>> though. And of course, to not have to import serialization library just
>> to get the annotations.
>
> import orange.serialization.Serializable;
>
> @nonSerialized class Bar { }
>
Good.

It's just would be really nice to have @nonSerialized and simillar somewhere in object.di with prescribed semantics. Then e.g. any serialization libraries including some 3rd party ones will play
by the same basic rules as far as user is concerned.

-- 
Dmitry Olshansky

On 2013-02-18 11:56, Dmitry Olshansky wrote:

> Good.
>
> It's just would be really nice to have @nonSerialized and simillar
> somewhere in object.di with prescribed semantics. Then e.g. any
> serialization libraries including some 3rd party ones will play
> by the same basic rules as far as user is concerned.

Yeah, when/if in Phobos that would be a good idea.

-- 
/Jacob Carlborg

Am Mon, 18 Feb 2013 12:03:29 +0100
schrieb Jacob Carlborg <doob@me.com>:

> On 2013-02-18 11:56, Dmitry Olshansky wrote:
> 
> > Good.
> >
> > It's just would be really nice to have @nonSerialized and simillar somewhere in object.di with prescribed semantics. Then e.g. any serialization libraries including some 3rd party ones will play by the same basic rules as far as user is concerned.
> 
> Yeah, when/if in Phobos that would be a good idea.
> 

Does this really belong into object.di? It adds more stuff to the global namespace (and druntime). Couldn't we just place "standard, library attributes" into std.attributes or something similar?

On 2013-02-18 12:51, Johannes Pfau wrote:

> Does this really belong into object.di? It adds more stuff to the
> global namespace (and druntime). Couldn't we just place "standard,
> library attributes" into std.attributes or something similar?

That's true. I don't know what's best.

-- 
/Jacob Carlborg

18-Feb-2013 15:51, Johannes Pfau пишет:
> Am Mon, 18 Feb 2013 12:03:29 +0100
> schrieb Jacob Carlborg <doob@me.com>:
>
>> On 2013-02-18 11:56, Dmitry Olshansky wrote:
>>
>>> Good.
>>>
>>> It's just would be really nice to have @nonSerialized and simillar
>>> somewhere in object.di with prescribed semantics. Then e.g. any
>>> serialization libraries including some 3rd party ones will play
>>> by the same basic rules as far as user is concerned.
>>
>> Yeah, when/if in Phobos that would be a good idea.
>>
>
> Does this really belong into object.di? It adds more stuff to the
> global namespace (and druntime). Couldn't we just place "standard,
> library attributes" into std.attributes or something similar?
>

I think it doesn't matter and shouldn't become a roadblock to its inclusion someplace standard. But if it's in object.d or core.attributes then druntime too can make use of it. It's a recurring problem that druntime has no access to certain useful things like std.traits simply because of their placement in fs ;) and I'd hate to see this problem repeat again.

I also suspect that it'd be around 10-20 attributes tops.

-- 
Dmitry Olshansky

On Monday, 18 February 2013 at 12:28:01 UTC, Dmitry Olshansky wrote:
> 18-Feb-2013 15:51, Johannes Pfau пишет:
>> Am Mon, 18 Feb 2013 12:03:29 +0100
>> schrieb Jacob Carlborg <doob@me.com>:
>>
>>> On 2013-02-18 11:56, Dmitry Olshansky wrote:
>>>
>>>> Good.
>>>>
>>>> It's just would be really nice to have @nonSerialized and simillar
>>>> somewhere in object.di with prescribed semantics. Then e.g. any
>>>> serialization libraries including some 3rd party ones will play
>>>> by the same basic rules as far as user is concerned.
>>>
>>> Yeah, when/if in Phobos that would be a good idea.
>>>
>>
>> Does this really belong into object.di? It adds more stuff to the
>> global namespace (and druntime). Couldn't we just place "standard,
>> library attributes" into std.attributes or something similar?
>>
>
> I think it doesn't matter and shouldn't become a roadblock to its inclusion someplace standard. But if it's in object.d or core.attributes then druntime too can make use of it. It's a recurring problem that druntime has no access to certain useful things like std.traits simply because of their placement in fs ;) and I'd hate to see this problem repeat again.
>
> I also suspect that it'd be around 10-20 attributes tops.

This has no meaning without the lib.

This belong with the lib or in a separated module that the lib uses as well.

On 2013-02-18 13:27, Dmitry Olshansky wrote:

> I think it doesn't matter and shouldn't become a roadblock to its
> inclusion someplace standard. But if it's in object.d or core.attributes
> then druntime too can make use of it. It's a recurring problem that
> druntime has no access to certain useful things like std.traits simply
> because of their placement in fs ;) and I'd hate to see this problem
> repeat again.

Yeah, druntime you use this attribute if it was added. We don't want to serialize threads and IO objects.

-- 
/Jacob Carlborg

On Mon, 18 Feb 2013 02:42:50 -0500, Jacob Carlborg <doob@me.com> wrote:

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

Then maybe I didn't understand deadalnix's point, or maybe you have solved his problem?  I don't know enough about your library.

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

If there isn't a problem, then we don't need a solution.  But if there is a problem, we may need something like this.

-Steve