Hello grauzone,
And even if Walter sanctions it, I wont use it because I'm very leery
of generating a system that automaticly reaches in from the outside
and mucks with private members. Whoever makes a type serializeable
needs to put at least some thought into how to serialize it. If it is
the type's
That's why I'd still require types to be marked as serializeable by
the programmer.
How would you do that aside from mixins?
But using mixins and adding unknown members from the
serialization machinery isn't that clean either.
I'm not going to fix it now, but I have a few ideas how I can only add the
public API to the types. That would be one non static serialization function
and a static deserialization function.
At least for all
those structs, it's truly annoying and unneeded. Having to use
different mixins for structs/classes sucks even more (wouldn't be
required if you wanted).
It isn't required, the difference is not struct vs. class but "do you care
about repeated references to instances of this type?"
By the way, how are you going to solve the other problems when
serializing D types? Here are some troublesome types:
- pointers?
class references are pointers, for struct and what not, I'll just use a similar
approach
- function pointers?
- delegates?
I won't
- unions?
for those I'll provide a way for the user to define the serialization
themselves.
- deserializing members that are const/immutable?
D1, when I get to that; the same way you generated them anywhere else? I
might even go with "unsafe" casts as I can be sure to get that correct.
- referential integrity across arrays and slices?
I won't
Also, it seems I just spotted a bug: floating point numbers loose
precision as they are formatted with "%s".
I suppose that should be "%A" I'll get to that at some point.
author, I'm comfortable with them saying "just do everything", but if
someone else is doing it, that is likely to get feet shot off. If I
made a generic "any type" function, it would recur into any
referenced types and either spew a big list of type that it's dealing
with (that people won't look at) or give no warning that it's walking
into new territory and that it may not be doing valid operations.
I didn't understand the last sentence.
First off there is not enough information to correctly generate sterilizers
for types. So the user has to do some thinking for most types. How do I make
the user thinks about how and for what types code is being generated?
Option 1) have the template run a paramg(msg,T.stringof) for each type and
hope the user don't just ignore the list.
Option 2) do nothing and be sure the user won't see anything.
Option 3) Make the user write per type code and error when they don't.
