Sets plus JSON

Allen Wirfs-Brock allen at
Thu Oct 4 11:30:02 PDT 2012

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>
>>> Date: October 3, 2012 10:15:57 AM PDT
>>> To: Herby Vojčík <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. 


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

More information about the es-discuss mailing list