On 10/4/2012 11:30 AM, Allen Wirfs-Brock wrote:
On Oct 4, 2012, at 11:02 AM, Nicholas C. Zakas wrote:
On 10/3/2012 4:44 PM, Allen Wirfs-Brock wrote:
(oops, forgot to reply-all)
Begin forwarded message:
*From: *Allen Wirfs-Brock <[email protected]
<mailto:[email protected]>>
*Date: *October 3, 2012 10:15:57 AM PDT
*To: *Herby Vojc(ík <[email protected] <mailto:[email protected]>>
*Subject: **Re: Sets plus JSON*
This is one of the reasons that it is important that Set (and Map,
etc.) are specified (and implemented) in a manner that makes them
fully subclassable. By subclassing, individual use cases for
serializing them can be kept distinct rather than multiple
libraries or subsystems fighting over who gets control of the
single implementation of Set.prototype.toJSON
That doesn't necessarily preclude a logical default, correct?
-N
If there is such a thing as a rational default. And it gets harder to
define as you move from Set on to Map.
In either case, you are really defining a new application schema layer
on top of JSON that requires custom deserialization. It won't be
meaningful to JSON clients that don't know your schema conventions.
Arguably, having { } as the the default JSON serialization for Set
and Map serves as a reminder to developers that if they want to use
JSON to serialize those abstraction they will need to coordinate with
clients in a deeper way than is required for simple arrays and struct
like objects.
Allen
I agree, I'm not sure there is a rational default for Map, but I think
there is one for Set as an array (and it seems like most people agreed).
I don't think that the ability to deserialize should be the deciding
factor. After all, Date objects are serialized into a string that isn't
deserialized back into a Date object unless you provide your own reviver.
-N
--
___________________________
Nicholas C. Zakas
http://www.nczonline.net
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
