www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Status of std.serialization?

reply std lib <email example.org> writes:
https://wiki.dlang.org/Review/std.serialization is dead, but is 
there hopes of adding it (or something like it) to phobos?
Jun 19 2019
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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
Jun 20 2019
next sibling parent Robert Schadek <rschadek symmetryinvestments.com> writes:
https://github.com/dlang/projects/issues/22
Jun 20 2019
prev sibling parent reply JN <666total wp.pl> writes:
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.
Jun 21 2019
next sibling parent Atila Neves <atila.neves gmail.com> writes:
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.
Jun 21 2019
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jun 21 2019
parent reply angel <andrey.gelman gmail.com> writes:
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 ?
Jun 22 2019
parent Jacob Carlborg <doob me.com> writes:
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
Jun 24 2019