Sets plus JSON

Rick Waldron waldron.rick at gmail.com
Thu Oct 4 17:27:48 PDT 2012


On Thu, Oct 4, 2012 at 8:07 PM, Nicholas C. Zakas <
standards at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121004/1f403577/attachment.html>


More information about the es-discuss mailing list