On Thursday, 22 August 2013 at 19:53:53 UTC, Jacob Carlborg wrote:
> On 2013-08-22 21:30, ilya-stromberg wrote:
>
>> Great! What about more difficult cases? For example, we have:
>>
>> class Foo
>> {
>>    int a;
>>    int b;
>> }
>>
>> After changes we have new class:
>>
>> class Foo
>> {
>>    long b;
>> }
>>
>> Can std.serialization load data to new class from old file? It should
>> ignore "a" and convert "b" from int to long.
>
> No it can't. It will throw an exception because it cannot find a "long" element:
>
> Could not find an element "long" with the attribute "key" with the value "b"

Jacob, can you use clearer error messages and provide more information for it?
You can type full class/sruct name (via std.traits.fullyQualifiedName) and field name and type: information can not be found in the archive

Please, put attention on it.

On Sunday, 1 September 2013 at 08:33:51 UTC, ilya-stromberg wrote:
> On Thursday, 22 August 2013 at 19:53:53 UTC, Jacob Carlborg wrote:
>> On 2013-08-22 21:30, ilya-stromberg wrote:
>>
>>> Great! What about more difficult cases? For example, we have:
>>>
>>> class Foo
>>> {
>>>   int a;
>>>   int b;
>>> }
>>>
>>> After changes we have new class:
>>>
>>> class Foo
>>> {
>>>   long b;
>>> }
>>>
>>> Can std.serialization load data to new class from old file? It should
>>> ignore "a" and convert "b" from int to long.
>>
>> No it can't. It will throw an exception because it cannot find a "long" element:
>>
>> Could not find an element "long" with the attribute "key" with the value "b"
>
> Jacob, can you use clearer error messages and provide more information for it?
> You can type full class/sruct name (via std.traits.fullyQualifiedName) and field name and type: information can not be found in the archive
>
> Please, put attention on it.

Sorry, I want to write:

Could not deserialize the field "b" with type "long" of class "Fouo": information can not be found in the archive.

On 2013-09-01 10:35, ilya-stromberg wrote:

> Sorry, I want to write:
>
> Could not deserialize the field "b" with type "long" of class "Fouo":
> information can not be found in the archive.

Yes, I could enhance the error message.

-- 
/Jacob Carlborg

On Wednesday, 14 August 2013 at 09:26:55 UTC, Jacob Carlborg wrote:
> On 2013-08-14 11:17, Tove wrote:
>> 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, can you add "@serializationName(string name)" UDA?
I saw the custom serialization example from documentation:
https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_serializable.html#.Serializable

class Foo : Serializable
{
    int a;

    void toData (Serializer serializer, Serializer.Data key)
    {
        serializer.serialize(a, "b");
    }

 void fromData (Serializer serializer, Serializer.Data key)
 {
     a = serializer.deserialize!(int)("b");
 }
}

Whith "@serializationName(string name)" attribute example should look like this:

class Foo
{
    @serializationName("b")
    int a;
}

Or for class/struct name:

@serializationName("Bar")
class Foo
{
    int a;
}

I think it's easier to use than custom serialization. And "@nonSerialized" UDA used for same purpose - simplify serialization customization.

Is it possible to implement?

On 2013-09-04 14:37, ilya-stromberg wrote:

> Jacob, can you add "@serializationName(string name)" UDA?
> I saw the custom serialization example from documentation:
> https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_serializable.html#.Serializable
>
>
> class Foo : Serializable
> {
>      int a;
>
>      void toData (Serializer serializer, Serializer.Data key)
>      {
>          serializer.serialize(a, "b");
>      }
>
>   void fromData (Serializer serializer, Serializer.Data key)
>   {
>       a = serializer.deserialize!(int)("b");
>   }
> }
>
> Whith "@serializationName(string name)" attribute example should look
> like this:
>
> class Foo
> {
>      @serializationName("b")
>      int a;
> }
>
> Or for class/struct name:
>
> @serializationName("Bar")
> class Foo
> {
>      int a;
> }
>
> I think it's easier to use than custom serialization. And
> "@nonSerialized" UDA used for same purpose - simplify serialization
> customization.

@nonSerialized is already available. At the bottom of the link you posted.

> Is it possible to implement?

Yes, the question is how much of these customization should be supported. It's easy to add at a later time if I don't add it from the beginning.

-- 
/Jacob Carlborg

On Thursday, 15 August 2013 at 07:07:13 UTC, Jacob Carlborg wrote:
> On 2013-08-14 21:55, ilya-stromberg wrote:
>
>> Can you use another serialization format and supports file output for
>> it? For example, can you use JSON, BSON or binary format?
>
> The idea of the library is that it can support multiple archive types. Currently only XML is implemented. I have been working on a binary archive for a while but I haven't finished it yet.

I am also working on my own binary archive implementation (I just want to quickly get a serialization of integral types, arrays and structs into binary) and I have a question:

What is the purpose of the "keys"?
If they really needed, can it be realised as option and disable them?
(I see also that they are forces to add a lot of duplicate functions.)

I guess if it succeeded binary format can be made very compact (and possibly faster) as Protocol Buffers.

On Thursday, 22 August 2013 at 13:13:48 UTC, Jacob Carlborg wrote:
> On 2013-08-22 13:57, ilya-stromberg wrote:
>
>> Can std.serialization load data from old file to the new class?
>
> Yes. In this case it will use the name of the instance fields when searching for values in the archive.

Is this the right way?

There are special formats (Protocol Buffers, for example) for a binary format what can be changed over time without breaking old code.

But for normal serialization is not this redundant?
Besides, search by name slower compared with other methods (field numbers, for example).

On 2013-09-21 15:13, mrd wrote:

> Is this the right way?
>
> There are special formats (Protocol Buffers, for example) for a binary
> format what can be changed over time without breaking old code.
>
> But for normal serialization is not this redundant?
> Besides, search by name slower compared with other methods (field
> numbers, for example).

Not necessarily. I could implement that by default it will use the field number, if the names doesn't match it could fallback to do a lookup by name.

I would like to avoid having a dependency on the orders of the fields.

-- 
/Jacob Carlborg

On 2013-09-21 14:48, mrd wrote:

> What is the purpose of the "keys"?

Fields are looked up by name. This is to avoid a dependency of the order of the fields. I guess I can look up by field order instead and fallback to a name look up if a name don't match.

> If they really needed, can it be realised as option and disable them?
> (I see also that they are forces to add a lot of duplicate functions.)

Yeah, I guess so.

> I guess if it succeeded binary format can be made very compact (and
> possibly faster) as Protocol Buffers.

I'm working on a binary archive as well. It ignores the name and look up by field order instead. It assume that the archived data and the class/struct has the same field order.

-- 
/Jacob Carlborg

Review summary: http://wiki.dlang.org/Review/std.serialization
( please review :) )