std.serialization: pre-voting review / discussion
ilya-stromberg
ilya-stromberg-2009 at yandex.ru
Wed Aug 28 09:02:03 PDT 2013
On Friday, 23 August 2013 at 13:39:47 UTC, Dicebot wrote:
> On Friday, 23 August 2013 at 13:34:04 UTC, ilya-stromberg wrote:
>> It's a serious issue. May be it's more important than range
>> support. For example, I have to change class (bug fixing, new
>> features, etc.), but it comparable with previos version
>> (example: it's always possible to convert "int" to "long"). I
>> that case I can't use std.serialization and have to write own
>> solution (for examle, save data in csv file).
>
> I don't think it as an issue at all. Behavior you want can't be
> defined in a generic way, at least not without lot of UDA help
> or similar declarative approach. In other words, the fact that
> those two classes are interchangeable in the context of the
> serialization exists only in the mind of programmer, not in D
> type system.
>
> More than that, such behavior goes seriously out of the line of
> D being strongly typed language. I think functionality you want
> does belong to a more specialized module, not generic
> std.serialization - maybe even format-specific.
Maybe you are right.
But I think it's not so difficult to implement, at least for
simle cases.
We can follow a simple rules, for example like this:
Does element "b" exists in the archive? - Yes.
Does element "b" has type "long"? - No, the type is "int".
Can we convert type "int" to "long"? - Yes, load element "b" to
tempory variable and convert it to "long":
int _b = 4;
long b = to!long(_b);
Is it difficult to implement?
Also, we can provide a few deserialize models: strict (like
current behavior) and smart (like example above). May be even 3
levels: strict, implicit conversions (like int to long) and
explicit conversions (like long to int).
More information about the Digitalmars-d
mailing list