www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Blog series to teach and show off D's metaprogramming by creating a

reply SealabJaster <sealabjaster gmail.com> writes:
https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1

Currently only the first post is out, as I'd like to collect 
feedback before writing any more.

The series is aimed at people new to D, or people who have heard 
of D, but haven't really explored its metaprogramming too much, 
hence certain things such as calling D's metaprogramming "often 
overlooked" as that tends to be true for non/new users of D.

Sorry in advance if this is the wrong forum group to post to, I 
didn't know whether to put it here or in the Learn group.

Future plans for this series:
  * Serialising structs (next up).

  * Serialising enums via their names, rather than values (and 
certain complications such as is(SomeEnum == int) being true).

  * Serialising classes.

  * Using UDAs to let classes and structs customise their fields.

  * Using __traits(compiles) to determine if a struct or class 
implements a custom (de)serialisation function.

  * Trying to think of how I can shoe horn mixin templates in, 
just so they're shown off.

I'm welcome to any other ideas to try and fit into the series. 
The serialiser won't be overly robust in terms of edge cases 
(such as nested classes/structs needing to be filtered out 
sometimes), but I'll try to mention them and provide a workaround 
where possible.

I've also taken to certain decisions in the code snippets, to try 
and reduce the amount of things I need to explain at once, and to 
hopefully make things more readable. e.g. Using "const string" 
instead of just "const" or "enum" (and then having to explain why 
not to use "enum" for strings), giving all if and else statements 
brackets to make things more readable (that's the plan at least), 
etc.

As for release schedule, I'm planning on getting at least one 
post out a week.

Other than feedback for the actual content of the blog, I'd also 
appreciate any feedback on visual style of the blog, since I'm 
quite a novice at CSS, let alone writing things like this.

While I'm not really capable of contributing to D in terms of 
improving phobos, or writing quality libraries, I'm hoping to at 
least be able to provide some educational material on what I feel 
makes D worth it as a way of contribution.
Oct 30 2019
next sibling parent reply GreatSam4sure <greatsam4sure gmail.com> writes:
On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster wrote:
 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1

 Currently only the first post is out, as I'd like to collect 
 feedback before writing any more.

 [...]
This is truly beautiful. Good work, a great tutorial indeed. Can you pick up the topic of compile time from the ground up. I will also love tutorial on DasbetterC. No tutorial that i am aware in this aspect of D Thanks a million times. I am awaiting the rest part of the tutorial
Oct 30 2019
parent SealabJaster <sealabjaster gmail.com> writes:
On Thursday, 31 October 2019 at 06:35:07 UTC, GreatSam4sure wrote:
 On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster 
 wrote:
 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1

 Currently only the first post is out, as I'd like to collect 
 feedback before writing any more.

 [...]
This is truly beautiful. Good work, a great tutorial indeed. Can you pick up the topic of compile time from the ground up. I will also love tutorial on DasbetterC. No tutorial that i am aware in this aspect of D Thanks a million times. I am awaiting the rest part of the tutorial
I'll definitely cover compile time in more depth at some point, but I don't want to put too much on myself right now, so any other topics will have to wait until after this current series is done. I'll admit I haven't messed around with DasBetterC since I haven't really had a use case for it yet. I'll mess around with it and maybe write something up, but no promises (and of course, it'll wait until after the serialiser series). Thank you for the kind words as well.
Oct 31 2019
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Looks like a very nice initiative! Looking forward to more!

A thought - host it on github? That way people can easily contribute
suggestions 
to it. You'd be in charge, of course, with what to do with those suggestions.
Oct 31 2019
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Thursday, 31 October 2019 at 07:38:46 UTC, Walter Bright wrote:
 Looks like a very nice initiative! Looking forward to more!

 A thought - host it on github? That way people can easily 
 contribute suggestions to it. You'd be in charge, of course, 
 with what to do with those suggestions.
Happy to say it is on github, https://github.com/SealabJaster/PersonalWebsite Issue is though, since it's my personal website I never thought anyone else would even look at the source, so it's got a bit of jank in it. For example, each blog post is going to be hand written HTML https://github.com/SealabJaster/PersonalWebsite/blob/master/PersonalWebsite/Views/BlogPosts/JsonSerialiser1.cshtml Though I might bother making it so I can write in markdown instead.
Oct 31 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/31/2019 2:51 AM, SealabJaster wrote:
 On Thursday, 31 October 2019 at 07:38:46 UTC, Walter Bright wrote:
 Looks like a very nice initiative! Looking forward to more!

 A thought - host it on github? That way people can easily contribute 
 suggestions to it. You'd be in charge, of course, with what to do with those 
 suggestions.
Happy to say it is on github, https://github.com/SealabJaster/PersonalWebsite
Excellent!
 Issue is though, since it's my personal website I never thought anyone else 
 would even look at the source, so it's got a bit of jank in it.
Github is an opportunity for you to build your brand and career.
 For example, each blog post is going to be hand written HTML 
 https://github.com/SealabJaster/PersonalWebsite/blob/master/PersonalWebsite/Views/BlogPosts/Js
nSerialiser1.cshtml 
 
 Though I might bother making it so I can write in markdown instead.
Markdown is a good choice. I've done the hand written HTML, it's agony.
Oct 31 2019
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster wrote:
 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1

 Currently only the first post is out, as I'd like to collect 
 feedback before writing any more.

 [...]
Great Job, keep pushing! If you don't know it, I suggest to have a look to the venerable Philippe Sigaud "D Template Tutorial" for inspiration [1]. It was by far the most complete and comprensive tutorial covering every aspect of the D Template programming. It would be great to have also an updated version of it ... [1] https://github.com/PhilippeSigaud/D-templates-tutorial
Oct 31 2019
parent reply GreatSam4sure <greatsam4sure gmail.com> writes:
On Thursday, 31 October 2019 at 09:02:07 UTC, Paolo Invernizzi 
wrote:
 On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster 
 wrote:
 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1

 Currently only the first post is out, as I'd like to collect 
 feedback before writing any more.

 [...]
Great Job, keep pushing! If you don't know it, I suggest to have a look to the venerable Philippe Sigaud "D Template Tutorial" for inspiration [1]. It was by far the most complete and comprensive tutorial covering every aspect of the D Template programming. It would be great to have also an updated version of it ... [1] https://github.com/PhilippeSigaud/D-templates-tutorial
The tutorial you referred to is very comprehensive but i am confess is hard to understand. I have read it twice but i did not understand. It might be my fault but i will prefer a simple start with the newbie in mind
Oct 31 2019
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 31 October 2019 at 09:07:18 UTC, GreatSam4sure wrote:
 On Thursday, 31 October 2019 at 09:02:07 UTC, Paolo Invernizzi 
 wrote:
 On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster 
 wrote:
 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1

 Currently only the first post is out, as I'd like to collect 
 feedback before writing any more.

 [...]
Great Job, keep pushing! If you don't know it, I suggest to have a look to the venerable Philippe Sigaud "D Template Tutorial" for inspiration [1]. It was by far the most complete and comprensive tutorial covering every aspect of the D Template programming. It would be great to have also an updated version of it ... [1] https://github.com/PhilippeSigaud/D-templates-tutorial
The tutorial you referred to is very comprehensive but i am confess is hard to understand. I have read it twice but i did not understand. It might be my fault but i will prefer a simple start with the newbie in mind
I agree with you, a simple start is valuable, so I think it's good to have someone who is covering that, so thanks! On the other side, I'm missing an updated version of a "advanced" tutorial, mainly because, as you have noticed, advanced template programming is not so easy to learn! Thanks for your job!
Oct 31 2019
parent SealabJaster <sealabjaster gmail.com> writes:
On Thursday, 31 October 2019 at 09:11:59 UTC, Paolo Invernizzi 
wrote:
 On Thursday, 31 October 2019 at 09:07:18 UTC, GreatSam4sure 
 wrote:
 On Thursday, 31 October 2019 at 09:02:07 UTC, Paolo Invernizzi 
 wrote:
 On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster 
 wrote:
 [...]
Great Job, keep pushing! If you don't know it, I suggest to have a look to the venerable Philippe Sigaud "D Template Tutorial" for inspiration [1]. It was by far the most complete and comprensive tutorial covering every aspect of the D Template programming. It would be great to have also an updated version of it ... [1] https://github.com/PhilippeSigaud/D-templates-tutorial
The tutorial you referred to is very comprehensive but i am confess is hard to understand. I have read it twice but i did not understand. It might be my fault but i will prefer a simple start with the newbie in mind
I agree with you, a simple start is valuable, so I think it's good to have someone who is covering that, so thanks! On the other side, I'm missing an updated version of a "advanced" tutorial, mainly because, as you have noticed, advanced template programming is not so easy to learn! Thanks for your job!
Ooh, that's quite the undertaking. I'll definitely give it some thought though, but as I said in another post, it'll have to be until after the serialiser set of posts are done. Would be an interesting thing to slowly work on over time though.
Oct 31 2019
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster wrote:
 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1
FYI, string is a built-in type. Regarding exercise 2. I would be very careful with deserializing a single character from JSON. First, because JSON doesn't support single characters. Second, you'll run into issues with Unicode. For example, you would need to know the exact JSON content, not just the type, to specify the type that should be deserialized. Example: assert(json.deserialise!char() == 'πŸ˜€'); The above will not work, because the type of 'πŸ˜€' is not `char`, it's `dchar`. The deserialization would need to throw an exception in this case, because 'πŸ˜€' won't fit in a `char`. It's much simpler to just not allow this use case. -- /Jacob Carlborg
Nov 01 2019
next sibling parent reply Ethan <gooberman gmail.com> writes:
On Friday, 1 November 2019 at 10:39:42 UTC, Jacob Carlborg wrote:
 FYI, string is a built-in type.
string is immutable(char)[], as we all know. Syntactic sugar, not exactly a built in type but treating it like one is often valuable. To follow on from this, I'll share my experience with doing exactly what SealabJaster is illustrating several times previously: You also want to catch const(char)[] and just plain char[] for JSON serialisation purposes. So a template constraint that catches all those is what you want instead of just is( T == string ). Dealing with wstring and dstring can be handled for bonus points... but eh, you only need to really worry about that if you are writing a library (or heavily use Phobos...).
Nov 01 2019
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On Friday, 1 November 2019 at 11:29:11 UTC, Ethan wrote:

 string is immutable(char)[], as we all know. Syntactic sugar, 
 not exactly a built in type but treating it like one is often 
 valuable.
It's an alias, but what it's aliased to is a built-in type. -- /Jacob Carlborg
Nov 01 2019
parent Ethan <gooberman gmail.com> writes:
On Friday, 1 November 2019 at 12:50:09 UTC, Jacob Carlborg wrote:
 It's an alias, but what it's aliased to is a built-in type.
A *slice* of a built-in type *with qualifiers*. The only way to simplify that description is to call it "syntactic sugar". "Built-in type" to describe the entire thing is only a half-truth.
Nov 01 2019
prev sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
On Friday, 1 November 2019 at 11:29:11 UTC, Ethan wrote:
 You also want to catch const(char)[] and just plain char[] for 
 JSON serialisation purposes. So a template constraint that 
 catches all those is what you want instead of just is( T == 
 string ).
I was definitely thinking of putting that in the first post, but thought it'd be better to leave it for later. Someone newer to D might not realise that a string is just a normal array/slice, instead of a special type (like in C++), so I didn't want to have to explain that yet. I'd also need to explain the differences between const and immutable briefly. I'm planning on going over it though in a post that goes over serialising arrays, which will likely be either the 4th or 5th one. Though, there's always the possiblity I'm just worrying and overthinking too much about putting too much into each post. I'm trying to make things easy to digest, and since I'm not used to writing things like this, I don't have a great grasp on how a person newer to D would be able to follow it.
Nov 01 2019
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Friday, 1 November 2019 at 21:14:56 UTC, SealabJaster wrote:
 ...
comments on this thread. I'd also like to clarify that the main purpose of this series is to demonstrate some of the thing of what D's metaprogramming can do, via the creation of the serialiser. The serialiser is just a by-product, so don't have the expectation that it's going to be amazingly robust. Though, maybe this is the wrong way to go about thing... If anything, I just hope to not spread mis-information, or overly bad practices.
Nov 03 2019
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Sunday, 3 November 2019 at 08:35:42 UTC, SealabJaster wrote:
 On Friday, 1 November 2019 at 21:14:56 UTC, SealabJaster wrote:
 ...
Sorry, seems it cut out the first half of that reply. New posts are out, and I don't want to spam Announce with new threads, so I'm just replying to this one. https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1_1 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser2
Nov 03 2019
next sibling parent reply JN <666total wp.pl> writes:
On Sunday, 3 November 2019 at 08:37:07 UTC, SealabJaster wrote:
 On Sunday, 3 November 2019 at 08:35:42 UTC, SealabJaster wrote:
 On Friday, 1 November 2019 at 21:14:56 UTC, SealabJaster wrote:
 ...
Sorry, seems it cut out the first half of that reply. New posts are out, and I don't want to spam Announce with new threads, so I'm just replying to this one. https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1_1 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser2
"This often seems to confuse people at first, especially those coming from other languages" I think what's confusing people is that enum (short for ENUMERATION) is suddenly used like a constant/alias.
Nov 03 2019
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 3 November 2019 at 21:35:18 UTC, JN wrote:
 On Sunday, 3 November 2019 at 08:37:07 UTC, SealabJaster wrote:
 On Sunday, 3 November 2019 at 08:35:42 UTC, SealabJaster wrote:
 On Friday, 1 November 2019 at 21:14:56 UTC, SealabJaster 
 wrote:
 ...
Sorry, seems it cut out the first half of that reply. New posts are out, and I don't want to spam Announce with new threads, so I'm just replying to this one. https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1_1 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser2
"This often seems to confuse people at first, especially those coming from other languages" I think what's confusing people is that enum (short for ENUMERATION) is suddenly used like a constant/alias.
I don't get why it confuses people. In all languages I know (C, C++, Java, Pascal, etc..) they are used to associate a compile time symbols with some quantities, i.e. the definition of constants. When an enumeration only consists of 1 value, then the enumeration is this value itself.
Nov 04 2019
next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Monday, 4 November 2019 at 08:25:11 UTC, Patrick Schluter 
wrote:
 On Sunday, 3 November 2019 at 21:35:18 UTC, JN wrote:
 On Sunday, 3 November 2019 at 08:37:07 UTC, SealabJaster wrote:
 On Sunday, 3 November 2019 at 08:35:42 UTC, SealabJaster 
 wrote:
 On Friday, 1 November 2019 at 21:14:56 UTC, SealabJaster 
 wrote:
 ...
Sorry, seems it cut out the first half of that reply. New posts are out, and I don't want to spam Announce with new threads, so I'm just replying to this one. https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1_1 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser2
"This often seems to confuse people at first, especially those coming from other languages" I think what's confusing people is that enum (short for ENUMERATION) is suddenly used like a constant/alias.
I don't get why it confuses people. In all languages I know (C, C++, Java, Pascal, etc..) they are used to associate a compile time symbols with some quantities, i.e. the definition of constants. When an enumeration only consists of 1 value, then the enumeration is this value itself.
Yes and no, because the fist case for using enum described at [1] is something very different:
 This defines a new type X which has values X.A=0, X.B=1, X.C=2:
 enum X { A, B, C }  // named enum
[1] https://dlang.org/spec/enum.html And it might be good to change the docs to point out the very often taken use case for declaring a singe compile time constant.
Nov 04 2019
prev sibling parent Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
On Monday, 4 November 2019 at 08:25:11 UTC, Patrick Schluter 
wrote:
 I don't get why it confuses people.
 In all languages I know (C, C++, Java, Pascal, etc..) they are 
 used to associate a compile time symbols with some quantities, 
 i.e. the definition of constants.
 When an enumeration only consists of 1 value, then the 
 enumeration is this value itself.
If I'm not mistaken `enum` must come from "enumerate" or "enumeration", so it's easy to instinctively think of enums as having multiple possible values; using such a word for a single value is a bit counter-intuitive IMO.
Nov 04 2019
prev sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
On Sunday, 3 November 2019 at 08:37:07 UTC, SealabJaster wrote:
 ...
Next post is out, I feel kind of iffy over how I went over classes, but I think for the most part it came out ok. I probably won't touch classes specifically in any future post though, unless I can think of something interesting to do with them. https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser3 that shows how __traits(hasMember), __traits(getMember)/__traits(allMembers), alongside some things in std.traits like Parameters and ReturnType, could be used instead of __traits(compiles). Also, until run.dlang.io's ability to create links is fixed, the usual links to snippets won't take you anywhere.
Nov 10 2019
parent reply JN <666total wp.pl> writes:
On Sunday, 10 November 2019 at 10:22:17 UTC, SealabJaster wrote:
 Next post is out, I feel kind of iffy over how I went over 
 classes, but I think for the most part it came out ok. I 
 probably won't touch classes specifically in any future post 
 though, unless I can think of something interesting to do with 
 them.
It's outside of the scope of the tutorial, but the "tough" part in serializing classes is realizing that they're a reference type rather than value type. Just like with serializing pointers, I could have two references pointing to the same class object, and a smart deserializer would create only one class object and point both references to it.
Nov 10 2019
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/10/19 5:50 PM, JN wrote:
 On Sunday, 10 November 2019 at 10:22:17 UTC, SealabJaster wrote:
 Next post is out, I feel kind of iffy over how I went over classes, 
 but I think for the most part it came out ok. I probably won't touch 
 classes specifically in any future post though, unless I can think of 
 something interesting to do with them.
It's outside of the scope of the tutorial, but the "tough" part in serializing classes is realizing that they're a reference type rather than value type. Just like with serializing pointers, I could have two references pointing to the same class object, and a smart deserializer would create only one class object and point both references to it.
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. -Steve
Nov 11 2019
prev sibling parent SealabJaster <sealabjaster gmail.com> writes:
On Friday, 1 November 2019 at 10:39:42 UTC, Jacob Carlborg wrote:
 On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster 
 wrote:
 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1
FYI, string is a built-in type.
I feel it's more of a weird gray area. As Ethan said it's more syntax sugar than a built-in type. However most code seems to treat strings as built-in; the language's string literals are useable with `string`; and they're common enough that they may as well be defined as built-in. So yea, even if I agree with Ethan that it's a "half-truth", I feel there's likely less confusion if I decide to clump it in as being built-in, so that'll be changed soon.
 Regarding exercise 2. I would be very careful with 
 deserializing a single character from JSON. First, because JSON 
 doesn't support single characters. Second, you'll run into 
 issues with Unicode. For example, you would need to know the 
 exact JSON content, not just the type, to specify the type that 
 should be deserialized. Example:

 assert(json.deserialise!char() == 'πŸ˜€');

 The above will not work, because the type of 'πŸ˜€' is not `char`, 
 it's `dchar`. The deserialization would need to throw an 
 exception in this case, because 'πŸ˜€' won't fit in a `char`. It's 
 much simpler to just not allow this use case.

 --
 /Jacob Carlborg
To be honest, those are all good points, and I can't really think of a counter argument. Regarding `wchar` and `dchar` though (and their string versions), I'm just not going to acknowledge they exist, since it's not a hard requirement, and it's just more things I need to explain, meaning more overhead on the reader.
Nov 01 2019
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/30/19 8:05 PM, SealabJaster wrote:
 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1
 
 Currently only the first post is out, as I'd like to collect feedback 
 before writing any more.
 
 The series is aimed at people new to D, or people who have heard of D, 
 but haven't really explored its metaprogramming too much, hence certain 
 things such as calling D's metaprogramming "often overlooked" as that 
 tends to be true for non/new users of D.
 
 Sorry in advance if this is the wrong forum group to post to, I didn't 
 know whether to put it here or in the Learn group.
 
 Future plans for this series:
  Β * Serialising structs (next up).
 
  Β * Serialising enums via their names, rather than values (and certain 
 complications such as is(SomeEnum == int) being true).
 
  Β * Serialising classes.
 
  Β * Using UDAs to let classes and structs customise their fields.
 
  Β * Using __traits(compiles) to determine if a struct or class 
 implements a custom (de)serialisation function.
 
  Β * Trying to think of how I can shoe horn mixin templates in, just so 
 they're shown off.
 
 I'm welcome to any other ideas to try and fit into the series. The 
 serialiser won't be overly robust in terms of edge cases (such as nested 
 classes/structs needing to be filtered out sometimes), but I'll try to 
 mention them and provide a workaround where possible.
 
 I've also taken to certain decisions in the code snippets, to try and 
 reduce the amount of things I need to explain at once, and to hopefully 
 make things more readable. e.g. Using "const string" instead of just 
 "const" or "enum" (and then having to explain why not to use "enum" for 
 strings), giving all if and else statements brackets to make things more 
 readable (that's the plan at least), etc.
 
 As for release schedule, I'm planning on getting at least one post out a 
 week.
 
 Other than feedback for the actual content of the blog, I'd also 
 appreciate any feedback on visual style of the blog, since I'm quite a 
 novice at CSS, let alone writing things like this.
 
 While I'm not really capable of contributing to D in terms of improving 
 phobos, or writing quality libraries, I'm hoping to at least be able to 
 provide some educational material on what I feel makes D worth it as a 
 way of contribution.
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. Also, if you want some inspiration for serialization/deserialization, check out jsoniopipe: http://code.dlang.org/packages/jsoniopipe 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. -Steve
Nov 11 2019
parent reply SealabJaster <sealabjaster gmail.com> writes:
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.
Nov 12 2019
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/12/19 4:15 AM, SealabJaster wrote:
 On Monday, 11 November 2019 at 16:56:31 UTC, Steven Schveighoffer wrote:
 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.
There's definitely not an automatic solution. However, in my jsoniopipe code, the base class can have a static function fromJSON that initializes the requested type. Such a thing has to be a member, but in theory could just be a registered callback. In my use case, I have a base class and all the derivatives in the same module (they are just messages). Here is some code that returns the base type that is portable to any such situation: static Base fromJSON(JT)(ref JT tokenizer, ReleasePolicy relPol) { // this creates a rewind point, so I can go back and parse the // object after finding the type. tokenizer.startCache(); if(tokenizer.parseTo("type")) // this part depends on the encoding { string t; // get the type name tokenizer.deserialize(t); import std.meta; // alias to the module for Base, which also contains all the // derivatives alias mod = __traits(parent, Base); enum isBase(string s) = is(__traits(getMember, mod, s) : Base) && !is(__traits(getMember, mod, s) == Base); // this gets all the classes in this module that are // derivatives of Base (except Base). D is so cool ;) alias Derivatives = Filter!(isBase, __traits(allMembers, mod)); // reset the tokenizer to read the whole JSON data for this object tokenizer.rewind(); tokenizer.endCache(); switch(t) { static foreach(typename; Derivatives) { // Note: MyType is the JSON string that designates the // type, your implementation may vary. case __traits(getMember, mod, typename).MyType: { auto result = new __traits(getMember, mod, typename); // defined by the library, does a rote // serialization of members. tokenizer.deserializeAllMembers(result, relPol); return result; } } default: assert(false, "Unknown type identifier: " ~ t); } } assert(false, "Couldn't find type identifier"); } Basically, I never have to touch this again, thanks D. Just add a new type that derives from Base with a proper MyType member, and it gets added to the list. It just has to be added to the module itself. If your class hierarchy is spread out in different files, you can make some kind of registration scheme to handle the deserialization. -Steve
Nov 12 2019
prev sibling next sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
On Tuesday, 12 November 2019 at 09:15:28 UTC, SealabJaster wrote:
 ...
Just wanted to quickly explain the delay for the next post. Basically just boils down to energy levels being non-existant, and run.dlang.io still being broken (Don't want to have a backlog of snippets to make). Hopefully both issues are resolved soon.
Nov 23 2019
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Saturday, 23 November 2019 at 22:38:22 UTC, SealabJaster wrote:
 On Tuesday, 12 November 2019 at 09:15:28 UTC, SealabJaster 
 wrote:
 ...
Just wanted to quickly explain the delay for the next post. Basically just boils down to energy levels being non-existant, and run.dlang.io still being broken (Don't want to have a backlog of snippets to make). Hopefully both issues are resolved soon.
4th post is now out at https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser4 It's on the shorter side, and not terribly interesting due to there being nothing new to explain, but hopefully the next post should sort that out. For both this post, and the 3rd post, I've swapped over to using https://godbolt.org for my snippet needs because I've lost hope of run.dlang.io being fixed anytime soon. Apologies for the delay, especially considering how "meatless" this post was.
Dec 03 2019
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Wednesday, 4 December 2019 at 03:13:28 UTC, SealabJaster wrote:
 ..
Final post of the year (and for a while) is out: https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser5 Once I've worked on the website's design + other things I want to get done, then I'll finish off the series with one or two more posts. After that I'm still thinking of what I may want to talk about. An idea from earlier in this thread is to talk about what exactly "compile-time" is in D, and how to determine what's run at compile-time, and what's ran at run-time. Regardless, I hope these posts are at least a tiny bit useful, even if their overall quality isn't great.
Dec 11 2019
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Wednesday, 11 December 2019 at 12:04:04 UTC, SealabJaster 
wrote:


Final post of this series (also sorry for the necro, but it's 
probably better than making a new post): 
https://bradley.chatha.dev/BlogPost/JsonSerialiser/6-mixin-template-automate-dlang-tutorial-metaprogramming

Pretty unhappy with its content, considering how long it's been 
since I wanted to write it, but hopefully its main purpose (to 
show off mixin template) is good enough.

I'd also like to apologise here for constantly embarrassing 
myself here (and I guess also on the Discord a year or so back), 
I'm likely to just not post here anymore just to save myself from 
the anxiety.

I hope this has been of some use to someone ^^. I want to write 
some more, but have no concrete plans for anything anytime soon.
May 06
next sibling parent reply Greatsam4sure <greatsam4sure yahoo.com> writes:
On Thursday, 7 May 2020 at 00:28:10 UTC, SealabJaster wrote:
 On Wednesday, 11 December 2019 at 12:04:04 UTC, SealabJaster 
 wrote:


 Final post of this series (also sorry for the necro, but it's 
 probably better than making a new post): 
 https://bradley.chatha.dev/BlogPost/JsonSerialiser/6-mixin-template-automate-dlang-tutorial-metaprogramming

 Pretty unhappy with its content, considering how long it's been 
 since I wanted to write it, but hopefully its main purpose (to 
 show off mixin template) is good enough.

 I'd also like to apologise here for constantly embarrassing 
 myself here (and I guess also on the Discord a year or so 
 back), I'm likely to just not post here anymore just to save 
 myself from the anxiety.

 I hope this has been of some use to someone ^^. I want to write 
 some more, but have no concrete plans for anything anytime soon.
This Series of tutorial is really nice. Please keep up the good work. Don't give up. There are those in this group that are guru no doubt but they don't write tutorials for the upcoming ones to learn. Dlang lacks great incentives for beginners. It seems it is a language design for the expert despite dlang is a easy to learn language Your tutorial is really down to earth. I really learn a lot from it.
May 07
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 7 May 2020 at 14:15:07 UTC, Greatsam4sure wrote:
 


 [snip]
Yeah, I thought it looked good. I make mistakes all the time. I find that saying dumb things out loud often will help me learn and make fewer mistakes in the future.
May 07
parent drug <drug2004 bk.ru> writes:
07.05.2020 18:03, jmh530 ΠΏΠΈΡˆΠ΅Ρ‚:
 I make mistakes all the time. I find that saying dumb things out loud 
 often will help me learn and make fewer mistakes in the future.
Totally agree
May 07
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/6/20 8:28 PM, SealabJaster wrote:
 On Wednesday, 11 December 2019 at 12:04:04 UTC, SealabJaster wrote:

 
 
 Final post of this series (also sorry for the necro, but it's probably 
 better than making a new post): 
 https://bradley.chatha.dev/BlogPost/JsonSerialiser/6-mixin-template-automate-dlang-tuto
ial-metaprogramming 
 
 
 Pretty unhappy with its content, considering how long it's been since I 
 wanted to write it, but hopefully its main purpose (to show off mixin 
 template) is good enough.
 
 I'd also like to apologise here for constantly embarrassing myself here 
 (and I guess also on the Discord a year or so back), I'm likely to just 
 not post here anymore just to save myself from the anxiety.
 
 I hope this has been of some use to someone ^^. I want to write some 
 more, but have no concrete plans for anything anytime soon.
I think you should not be embarrassed. I hope you don't feel bad based on my feedback! It was intended as helpful not as a complaint. It's always good to have more content on D and your blog posts aren't bad. I hope you continue. -Steve
May 07
prev sibling parent Jacob Carlborg <doob me.com> writes:
On Tuesday, 12 November 2019 at 09:15:28 UTC, SealabJaster wrote:

 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.
They way I handled this in Orange [1] which allows to (de)serialize third party types which you don't have any control of. First, structs have the same problem as classes: there can be private members. They way this is handled is to use `.tupleof`. `.tupleof` will bypass the protection and allows to read and write private fields: module foo; class Foo { private int a; int getA() { return a; } } module main; import std.stdio; import foo; void main() { auto foo = new Foo; foo.tupleof[0] = 3; assert(foo.getA == 3); assert(foo.tupleof[0] == 3); } `.tupleof` is used both for serialization and deserialization. To create an instance of a class use the same way as the runtime does. This function [2] is called by the compiler when the code contains "new Object" (extracted to Orange here [3]). This will not call a constructor, but that's fine since we will set the fields anyway directly after. Orange also offers a way to tweak the (de)serialization process with hooks. You can define methods in your structs or classes with any of the following UDAs: `onSerializing`, `onSerialized`, `onDeserializing` and `onDeserialized`. These method will be called (if they exist) before/after the (de)serialization process [4]. This allows you do preform some post-processing that might be needed since no constructor has been called on deserialization. When it comes to (de)serializing derived types through a base class reference Orange requires you do register all derived types [5]. Then there's the problem with non-mutable fields and instances as well. But you can just cast away those when deserializing. There's also the issue with circular references [6]. But that's pretty easy to solve by storing all serialized instances to see if they have already been serialized or not. [1] http://github.com/jacob-carlborg/orange [2] https://github.com/dlang/druntime/blob/873fac33014c5af680c4bed69bb74cb0f192198a/src/rt/lifetime.d#L73 [3] https://github.com/jacob-carlborg/orange/blob/90f1dbb0097ba4a319805bfb7d109f7038418ac6/orange/util/Reflection.d#L149-L183 [4] https://github.com/jacob-carlborg/orange/blob/master/tests/Events.d [5] https://github.com/jacob-carlborg/orange/blob/90f1dbb0097ba4a319805bfb7d109f7038418ac6/orange/serialization/Serializer.d#L241-L262 [6] https://github.com/jacob-carlborg/orange/blob/master/tests/CircularReference.d -- /Jacob Carlborg
Dec 03 2019