BCS wrote:
That's why I'd still require types to be marked as serializeable by
the programmer.
How would you do that aside from mixins?
Make the user implement a marker interface, or let him provide a
(single) special class member which fulfill the same function, or
introduce annotations into the language. As far as marking goes, a mixin
would be OK too, but as I said, I don't like adding arbitrary members
into the user's scope without the user knowing.
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?"
IMHO a relatively useless optimization, that will only confuse the user.
It will introduce subtle bugs if objects accidentally are "repeated"
instead of serialized only once.
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
That's not really the problem here. You have no idea where a pointer
points to. Is it a pointer to a new'ed memory block? Does it point into
an object? Does it point into an array? Into the data segment?
The GC provides no API to find out. You may be able to handle some cases
above, but not all.
- function pointers?
- delegates?
I won't
Forces the user to use interfaces instead of delegates.
- 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.
In D1, it comes for free: you simply don't need to handle it.
But yes, it looks like you have to use dirty tricks in D2.
- referential integrity across arrays and slices?
I won't
I wonder if anyone (I mean, especially user of a serialization library)
would disagree with that choice. Sure, there are valid D programs that
would break with this, but is relying on this really clean?
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.
Oh, you mean if there are types in the object graphs the serializer
can't deal with it? But how would option 2) work?
