Hi Greg,
> I don't think we have much control over null values. As far as I know, null 
> is null - can't get any other information about it; i.e. this conditional 
> will always return false:
Ok, excuse me, it was re.thinking at something as i had in some
particular situations (where i needed to transform a particular
instance of a class into null or a marker for null, and the opposite
... for example do you remember by BinarySerializerEnhanced of many
months ago ?), but here you can ignore this.

> But null is a supported JSON type, so this shouldn't really be an issue. As 
> for dates - why not just encode them as strings?
OK, but i think that also for performance reason this should be better ...
Then, my idea if  for a more general way to handle anything not
directly supported by the Serializer, but i understand that this could
add more complexity than benefits, at least at the moment ... because
in some cases this could lead to bad

So at concept level, if i could attach optional handlers (my classes
extending a base Pivot class or interface for this) for
serializing/deserializing some my classes, i could give to the
serializer the real data without making conversions (that would be
done by handlers inside the Serializer and only if enabled and for
example after an exception).

For example, as a sample, we could implement a sample
SerializerHandler/Transformer (mhhh it's better another name i think)
and (but only when added the an instance of JSONSerializer) trying to
convert a date object value into a form like
"handler-full-class-name:1234567890" where the value is for example to
toMillis() value, that's more efficient of the toString when generated
and the parse when read ...
Mhhh now i think that reading a json (well-formed, ok) with this info
inside would be not so simple (and processing this value by the
related handler), suggestions ?

After this, what do you think ?
If you what i could try to implement a simple version of this (after
finishing the other stuff i have ... but for example on the
Persistence I'd like some feedback) ... tell me.


Oh, if other Pivot Developers have ideas/suggestions, are welcome, as always.

Thanks again,
Sandro

Reply via email to