Blog series to teach and show off D's metaprogramming by creating a JSON serialiser

[SealabJaster]

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.