https://wiki.dlang.org/Review/std.serialization is dead, but is there hopes of adding it (or something like it) to phobos?

On Wednesday, 19 June 2019 at 22:42:07 UTC, std lib wrote:
> https://wiki.dlang.org/Review/std.serialization is dead, but is there hopes of adding it (or something like it) to phobos?

Not an answer to your question, but still on topic: http://dconf.org/2019/talks/schveighoffer.html

https://github.com/dlang/projects/issues/22

On Thursday, 20 June 2019 at 09:29:09 UTC, Bastiaan Veelo wrote:
> On Wednesday, 19 June 2019 at 22:42:07 UTC, std lib wrote:
>> https://wiki.dlang.org/Review/std.serialization is dead, but is there hopes of adding it (or something like it) to phobos?
>
> Not an answer to your question, but still on topic: http://dconf.org/2019/talks/schveighoffer.html

Serialization can be tricky to make. Sure, at first you can be like "just use tupleof/static foreach/_allMembers and you have your serialization, D is so easy and awesome!". But then you hit some tougher usecases for serialization:

- adding serialization support for custom types (especially ones you can't modify)
- serializing/deserializing polymorphic types by base class reference
- multiple formats - json/xml/yaml/binary

I think any std.serialization attempt would need to have a modular approach with at least two modules. One module would be output-format agnostic and responsible for annotations. Marking variables which should be serialized, ones that shouldn't, ones that should be but with a different name, and with some form of serializeTo/deserializeFrom methods. The other module would be output format specific, something like XmlSerialization, which takes the definitions created by the first module and converts the data from/to the expected format.

On Friday, 21 June 2019 at 07:22:07 UTC, JN wrote:
> On Thursday, 20 June 2019 at 09:29:09 UTC, Bastiaan Veelo wrote:
>> [...]
>
> Serialization can be tricky to make. Sure, at first you can be like "just use tupleof/static foreach/_allMembers and you have your serialization, D is so easy and awesome!". But then you hit some tougher usecases for serialization:
>
> [...]

I agree. I started rewriting cerealed to be like this but haven't gone back to it in a while.

On 2019-06-21 09:22, JN wrote:

> Serialization can be tricky to make. Sure, at first you can be like
> "just use tupleof/static foreach/_allMembers and you have your
> serialization, D is so easy and awesome!". But then you hit some tougher
> usecases for serialization:
>
> - adding serialization support for custom types (especially ones you
> can't modify)
> - serializing/deserializing polymorphic types by base class reference
> - multiple formats - json/xml/yaml/binary

All these are supported by Orange [1]. Although only one format (XML) is currently implemented.

> I think any std.serialization attempt would need to have a modular
> approach with at least two modules. One module would be output-format
> agnostic and responsible for annotations. Marking variables which should
> be serialized, ones that shouldn't, ones that should be but with a
> different name, and with some form of serializeTo/deserializeFrom
> methods. The other module would be output format specific, something
> like XmlSerialization, which takes the definitions created by the first
> module and converts the data from/to the expected format.

That's exactly how Orange is implemented [1]

[1] http://github.com/jacob-carlborg/orange/

-- 
/Jacob Carlborg

On Friday, 21 June 2019 at 19:09:31 UTC, Jacob Carlborg wrote:
> On 2019-06-21 09:22, JN wrote:
>
>> Serialization can be tricky to make. Sure, at first you can be like
>> "just use tupleof/static foreach/_allMembers and you have your
>> serialization, D is so easy and awesome!". But then you hit some tougher
>> usecases for serialization:
>>
>> - adding serialization support for custom types (especially ones you
>> can't modify)
>> - serializing/deserializing polymorphic types by base class reference
>> - multiple formats - json/xml/yaml/binary
>
> All these are supported by Orange [1]. Although only one format (XML) is currently implemented.
>
>> I think any std.serialization attempt would need to have a modular
>> approach with at least two modules. One module would be output-format
>> agnostic and responsible for annotations. Marking variables which should
>> be serialized, ones that shouldn't, ones that should be but with a
>> different name, and with some form of serializeTo/deserializeFrom
>> methods. The other module would be output format specific, something
>> like XmlSerialization, which takes the definitions created by the first
>> module and converts the data from/to the expected format.
>
> That's exactly how Orange is implemented [1]
>
> [1] http://github.com/jacob-carlborg/orange/


Did you try to promote Orange to std.serialization ?

On 2019-06-22 21:59, angel wrote:

> Did you try to promote Orange to std.serialization ?

Yes: https://wiki.dlang.org/Review/std.serialization

-- 
/Jacob Carlborg