Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
June 19, 2019 Status of std.serialization? | ||||
---|---|---|---|---|
| ||||
https://wiki.dlang.org/Review/std.serialization is dead, but is there hopes of adding it (or something like it) to phobos? |
June 20, 2019 Re: Status of std.serialization? | ||||
---|---|---|---|---|
| ||||
Posted in reply to std lib | 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 |
June 20, 2019 Re: Status of std.serialization? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bastiaan Veelo | https://github.com/dlang/projects/issues/22 |
June 21, 2019 Re: Status of std.serialization? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bastiaan Veelo | 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.
|
June 21, 2019 Re: Status of std.serialization? | ||||
---|---|---|---|---|
| ||||
Posted in reply to JN | 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.
|
June 21, 2019 Re: Status of std.serialization? | ||||
---|---|---|---|---|
| ||||
Posted in reply to JN | 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 |
June 22, 2019 Re: Status of std.serialization? | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 ?
|
June 24, 2019 Re: Status of std.serialization? | ||||
---|---|---|---|---|
| ||||
Posted in reply to angel | 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 |
Copyright © 1999-2021 by the D Language Foundation