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]>
>>> Date: October 3, 2012 10:15:57 AM PDT
>>> To: Herby Vojčík <[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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
