On 17-04-2012 10:13, Walter Bright wrote:
On 4/17/2012 1:10 AM, Walter Bright wrote:
On 4/16/2012 11:50 PM, Jacob Carlborg wrote:
On 2012-04-17 08:33, Walter Bright wrote:
On 4/16/2012 11:26 PM, Jacob Carlborg wrote:
Then it won't be possible to serialize third party types if they don't
implements ISerializable. In this case, this solution is no better
then manually
registering types. Actually it's worse, since I can manually register
third
party types.
I'm not so sure in D that you can serialize arbitrary types without
them
designed to be serializable. For example, what will you do with unions?
Pointers to global data?
Not all types are serializable of course.
How would you know if they are or aren't, when dynamically loading stuff?
Essentially, I'm concerned with a vast amount of data being generated
for every type and inserted into the executables (which are already
large). Even worse, I'm concerned that such a feature will not "just
work" when one wants to serialize a class that wasn't designed to be
serialized, and it'll come off as a crappy half-assed buggy misfeature.
Would turning on global reflection data generation with a compiler
switch be reasonable? Then when libraries query for reflection
information, they just have to check whether it's actually there (and if
not, most likely error).
Anyway, I don't think reflection has the potential to be a misfeature;
that's stretching it. Redundancy can certainly be incurred, but with a
switch to enable reflection, it would only happen when the user actually
wants it to.
As for the just works factor - if the serialization library is designed
well enough (which I'm confident Jacob's library either is can be made
to be), it isn't really a problem. Serializing a graph of objects is
pretty standard (see e.g. .NET binary serialization).
Even better, the library could just error out (instead of producing
garbage) when it discovers that it can't serialize a type in any
sensible fashion.
--
- Alex
