On Thu, Oct 4, 2012 at 8:07 PM, Nicholas C. Zakas <
standa...@nczconsulting.com> wrote:
>
> On 10/4/2012 11:30 AM, Allen Wirfs-Brock wrote:
>
>
>
> 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.
>
Yes, I still agree with the Set->(as Array)->JSON
and...
new Date(
JSON.parse(
JSON.stringify(
new Date()
)
)
);
Results in Date object, as I would expect. So I'd expect...
new Set(
JSON.parse(
JSON.stringify(
new Set([1,2,3,4,5])
)
)
);
To result in a Set
Rick
>
>
> -N
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
