Serialization for D. Comments, please!

BCS none at
Sun Jun 14 08:15:31 PDT 2009

Hello grauzone,

> 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, 

that would work (for classes) but IMHO the side effects of that are more 
invasive and it still ends up mucking with internal state from the outside

> or let him provide a
> (single) special class member which fulfill the same function,

What's the difference between one and two?

> or
> introduce annotations into the language.

NO, not an option.

> 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.

how about if what the mixins add is documented?

>>> 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.

Well, I can switch the default but, in my experience, most of the time repetition 
doesn't matter. I also dissagree on the "relatively useless optimization" 
bit, it adds some not exactly trivial overhead in about 3 or 4 different 

>>> 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.

What I can't handle will be documented as unsupported.

>>> - function pointers?
>>> - delegates?
>> I won't
> Forces the user to use interfaces instead of delegates.

interfaces are not supported either.

>>> - 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?

That's what I'm hoping for. D is to low level for setting up serialization 
to be completely automatic. The programmer will have to be careful how things 
are set up. My go is to make that as easy as I can.

>> 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?

Almost, I think. I'm looking at the case where a new types is /added/ to 
the the object graph at some point removed form the use of the sterilizer. 
Someone needs to be informed that new types are being serialized and that 
they need to make sure it's working correctly.

> But how would option 2) work?

It dosn't

More information about the Digitalmars-d-announce mailing list