Sets plus JSON

Nicholas C. Zakas standards at
Thu Oct 4 17:07:49 PDT 2012

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 <allen at 
>>>> <mailto:allen at>>
>>>> *Date: *October 3, 2012 10:15:57 AM PDT
>>>> *To: *Herby Vojc(ík <herby at <mailto:herby at>>
>>>> *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.


Nicholas C. Zakas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list