Hello grauzone,

BCS wrote:

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

Oh really?

I haven't used a graph data structure in some time. Most of them have
been trees. And the cases I can think of, the repeated reference bit
has been central the the structure so the chances of getting it wrong
(or of missing it under test) are about nil.

IMO, most tree-like structures are still full graphs in memory,
because they often contain "parent" pointers, or point back to a
parent indirectly (e.g. even if a generic tree data structure is
implemented without parent pointers, the data element itself might
contain such pointers).

I'm referring to data structure that I could add serialization to, e.i. ones where I would know of they have parent references. I still stand by my assertion.


OTOH pointers to struct are not value types...

Pointers are a whole different thing. A pointer can still point to a
"value" type, because that struct might be embedded within an object
(a class member that's a struct).


pointers to members won't be supported any time soon.

interfaces are not supported either.

But supporting interfaces would be very simple.

It wouldn't be hard in the current form (you would add a mixin to the
interface as well) but the non-mixin, outside in approach would have
all sorts of interesting issues like how to get the correct
sterilizer function.

Huh? You can simple cast the interface to an object.

That is not safe. not all interface instances are D objects.

And then cast the
object to the serializeable type.

Cast only works if you know /at compile time/ what type to cast to so I don't think that's going to work.
You need to be able to do that
anyway, because object references can be of the type "Object", and
there's no way you'd add your serialize mixin to Object.

And that just brought up another issue: how do you serialize a class that only ever shows up as a base class reference? The lib has no way to /find/ the type at compile time so it has no way to generate code to deal with it.


Also, is you writing "sterilizer" a typo or not?

typo (is it in the lib or just this thread?) I'd be even worse without a spellchecker :(


Reply via email to