On Monday, 11 November 2019 at 16:56:31 UTC, Steven Schveighoffer
wrote:
On 10/30/19 8:05 PM, SealabJaster wrote:
...
Looks like a great idea! Sounds very similar to what I've been
learning over the past 5 years or so.
See my dconf presentation from this year.
I had a quick skim, and seems like it touches upon a lot of stuff
I want to talk about. Will give it a proper watch later today :)
Also, if you want some inspiration for
serialization/deserialization, check out jsoniopipe:
http://code.dlang.org/packages/jsoniopipe
Will also give that a look over.
Simply put, I think it's great to use D overloading as much as
possible instead of static if (reading your first article). OK,
now reading the "alternate function layout", I see you did do
that :) That's how I did mine, and I think it reads much nicer.
I do actually prefer to go with overloads (I usually use a hybrid
of overloads + static ifs, depending on the case), but it made
the code snippets a bit harder to read and follow (imo) so I went
with a single function instead.
The tough part about serializing classes is if the class is not
final, how do you serialize the derived data. It requires some
sort of user help to
tell it how to get at the data.
And if you do allow things such as letting classes have a
'deserialise' member function which can be overloaded, you still
need to create or be given an instance of the class beforehand,
which brings things back around to the "constructor issue" in the
latest post.
I don't quite know if there's actually an automatic solution for
classes that covers most cases? Anything I can think of places
limitations in some form or another.
