On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg wrote:
> On 2013-08-14 10:19, Tyler Jameson Little wrote:
>> - Typo: NonSerialized example should read NonSerialized!(b)
>
> No, it's not a typo. If you read the documentation you'll see that:
>
> "If no fields or "this" is specified, it indicates that the whole class/struct should not be (de)serialized."

I understand the need for Orange to be backwards compatible, but for std.serialization, why isn't the old-style mixin simply removed in favor of the UDA.

Furthermore for "template NonSerialized(Fields...)" there is an example, while for the new style "struct nonSerialized;" there isn't!

I find the newstyle both more intuitive and you also more dry not duplicating the identifier: "int b; mixin NonSerialized!(b)"

@nonSerialized struct Foo
{
    int a;
    int b;
    int c;
}

struct Bar
{
    int a;
    int b;
    @nonSerialized int c;
}

On 2013-08-14 11:15, Tyler Jameson Little wrote:

> Well, std.xml needs to be replaced anyway, so it's probably not a good
> limitation to have. It may take some work to replace it correctly though...

No, but should std.serialization be on hold until std.xml is replaced?

> I'm mostly interested in reducing memory. If I'm (de)serializing a large
> object or lots of objects, this could become an issue.
>
> Related question: Have you looked at how much this relies on the GC?

I haven't done any measurements. It will use the GC to deserialize values that are normally heap allocated, that is: arrays, associative arrays, objects, strings and so on. In addition to that, a pointer to each deserialized value is stored in an associative array.

-- 
/Jacob Carlborg

On Wednesday, 14 August 2013 at 09:17:44 UTC, Tove wrote:
> On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg wrote:
>> On 2013-08-14 10:19, Tyler Jameson Little wrote:
>>> - Typo: NonSerialized example should read NonSerialized!(b)
>>
>> No, it's not a typo. If you read the documentation you'll see that:
>>
>> "If no fields or "this" is specified, it indicates that the whole class/struct should not be (de)serialized."
>
> I understand the need for Orange to be backwards compatible, but for std.serialization, why isn't the old-style mixin simply removed in favor of the UDA.
>
> Furthermore for "template NonSerialized(Fields...)" there is an example, while for the new style "struct nonSerialized;" there isn't!
>
> I find the newstyle both more intuitive and you also more dry not duplicating the identifier: "int b; mixin NonSerialized!(b)"
>
> @nonSerialized struct Foo
> {
>     int a;
>     int b;
>     int c;
> }
>
> struct Bar
> {
>     int a;
>     int b;
>     @nonSerialized int c;
> }

I like this a lot more. Phobos just needs to be compatible with the current release, so backwards compat is a non-issue here.

On 2013-08-14 11:17, Tove wrote:

> I understand the need for Orange to be backwards compatible, but for
> std.serialization, why isn't the old-style mixin simply removed in favor
> of the UDA.

I don't know, it doesn't really hurt to be present. And for anyone using Orange they only need to change the imports to have it work with std.serialization.

> Furthermore for "template NonSerialized(Fields...)" there is an example,
> while for the new style "struct nonSerialized;" there isn't!

Good point, I'll add an example.

> I find the newstyle both more intuitive and you also more dry not
> duplicating the identifier: "int b; mixin NonSerialized!(b)"
>
> @nonSerialized struct Foo
> {
>      int a;
>      int b;
>      int c;
> }
>
> struct Bar
> {
>      int a;
>      int b;
>      @nonSerialized int c;
> }

Absolutely.

-- 
/Jacob Carlborg

On 2013-08-14 11:25, Tyler Jameson Little wrote:

> I like this a lot more. Phobos just needs to be compatible with the
> current release, so backwards compat is a non-issue here.

I guess this is why we have this thread. I would like to hear comments from a couple of others as well about this before deciding.

-- 
/Jacob Carlborg

On Wednesday, 14 August 2013 at 07:40:13 UTC, Jacob Carlborg wrote:
> I have documented the package for what it is, not for what it's not. It's a package for serialization, not a RCP or network package....
>
> You seem to like me to write a comparison to Thrift in the documentation. You have to make the comparison yourself.

Wishful thinking aside, they are competitors. The fact that you haven't already done this comparison is unfortunate. I've already done that comparison, tried Orange, and found it wanting. If you don't want everyone else to do the same, you should answer the questions outlined so that it can be positioned appropriately in people's minds.

If you'd like examples of how to present design rationale, using contrast for illustration, consider the example of Stroustrup's presentation of C++ features in any of his several books. Contrasting analysis is often essential in describing the history, design and rationale for your work; the "related work" section of any technical publication is required by reviewers. You should provide it if you don't want your work to be dismissed out of hand.

Many if not most modern serialization libraries do address transport, and it is critical to the most common use case for serialization: as a developer, I want to move data between two different environments, be they hosts, memories, disk, process, thread, or different languages; so that I can store and process data non-locally and in a non-sequential fashion.

For Orange, you can simply say that you have no transport support, and perhaps describe why you don't consider it (e.g. what use case were you designing for?), and that will suffice to answer number three (3).  In addition, there are still eight other salient issues.

I provided this outline to assist you in describing your work. You'll need to be more specific about where you are confused if you don't understand a particular issue. Ignoring issues won't make them go away, it will just make others ignore and go away from your work.

On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote:
> Wishful thinking aside, they are competitors.

They are not. `std.serialization` does not and should not compete in Thrift domain. In fact, if something like this can be found in proposal you should point to it and it will be discussed as a possible removal candidate.

Your input is valuable put please reconsider it without this wrong assumption.

On Wednesday, 14 August 2013 at 09:28:20 UTC, Jacob Carlborg wrote:
> On 2013-08-14 11:25, Tyler Jameson Little wrote:
>
>> I like this a lot more. Phobos just needs to be compatible with the
>> current release, so backwards compat is a non-issue here.
>
> I guess this is why we have this thread. I would like to hear comments from a couple of others as well about this before deciding.

I think we should avoid mixins as much as it possible.
UDA @nonSerialized looks much better, so I think we should use it.
Of course, we can leave template NonSerialized(Fields...) for backwards compatible with Orange and, maybe, deprecate it.

On 2013-08-14 16:15, ilya-stromberg wrote:

> I think we should avoid mixins as much as it possible.
> UDA @nonSerialized looks much better, so I think we should use it.
> Of course, we can leave template NonSerialized(Fields...) for backwards
> compatible with Orange and, maybe, deprecate it.

Of course UDA's should be the primary use for this. The question is should NonSerialized be included at all? Should it be included and deprecated or should it just be included?

-- 
/Jacob Carlborg

On Wednesday, 14 August 2013 at 14:34:58 UTC, Jacob Carlborg wrote:
> Should it be included and deprecated or should it just be included?

What is the point of including something into Phobos and immediately deprecating it? It is first inclusion, so there are no backwards compatibility concerns.