Sets plus JSON

Herby Vojčík herby at mailbox.sk
Wed Oct 3 11:07:49 PDT 2012



Rick Waldron wrote:
>
>
> On Wed, Oct 3, 2012 at 1:57 PM, Herby Vojčík <herby at mailbox.sk
> <mailto:herby at mailbox.sk>> wrote:
>
>
>
>     Rick Waldron wrote:
>
>
>
>         On Wed, Oct 3, 2012 at 12:56 PM, Herby Vojčík <herby at mailbox.sk
>         <mailto:herby at mailbox.sk>
>         <mailto:herby at mailbox.sk <mailto:herby at mailbox.sk>>> wrote:
>
>
>
>              Nicholas C. Zakas wrote:
>
>                  After a little more experimenting with sets (still a
>         really big
>                  fan!!),
>                  I've come across an interesting problem. Basically, I found
>                  myself using
>                  a set and then wanting to convert that into JSON for
>         storage.
>                  JSON.stringify() run on a set returns "{}", because
>         it's an object
>                  without any enumerable properties. I'm wondering if
>         that's the
>                  correct
>                  behavior because a set is really more like an array
>         than it is an
>                  object, and perhaps it would be best to define a
>         toJSON() method for
>                  sets such as:
>
>                  Set.prototype.toJSON = function() {
>                  return Array.from(this);
>
>              It depends... you should be able to reread it, so the best
>         thing
>              would proably be to use matching set of transformers for both
>              stringify and parse. I personally would rather see
>         something like
>                       { _Set_from_: Array.from(this) }
>              here.
>
>                  };
>
>
>
>         The revived array can be passed as an arg to new Set(revived) :
>
>         new Set(JSON.parse(s.toJSON()))
>
>
>     I am talking about deep nested structure with (possibly) multiple
>     sets all over. Your solution is unusable, you need to explicitly
>     know where the arrayified sets are.
>
>
> Fair enough, my solution definitely doesn't scale.
>
> In that case, I'd say it's not the language's job to try and guess what
> the user code wanted to do with a serious of deeply nested, stringified
> arrays in a JSON string. Seems like a non-starter.

I am worried you are accusing me of something Bad (TM) I did not 
actually proposed.

I said, ones cannot used .toJSON because you need to read it back, so 
you should serialize / deserialize by some protocol, for which you need 
to supply the transforming functions, JSON.parse as well as 
JSON.stringify have extra parameters for them (plus contemplated the 
idea that such composable wrappers/unwrappers for Sets, Maps etc. could 
be supplied because they can be handy, but probably library is the 
better level for this than the language).

> Rick
>
>         Introducing another Set constructor just to wrap the above is
>         early-warning feature creep. toJSON is an intuitive addition

Definitely not "feature-creep another Set constructor".

>
>         Rick
>
>
>     Herby


More information about the es-discuss mailing list