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
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
next sibling parent Robert Schadek <rschadek symmetryinvestments.com> writes:
https://github.com/dlang/projects/issues/22
Jun 20
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
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
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
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
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