Sets plus JSON

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



Rick Waldron wrote:
>
>
> On Wed, Oct 3, 2012 at 2:07 PM, Herby Vojčík <herby at mailbox.sk
> <mailto:herby at mailbox.sk>> wrote:
>
>
>
>     Rick Waldron wrote:
>
>
>
>         On Wed, Oct 3, 2012 at 1:57 PM, Herby Vojčík <herby at mailbox.sk
>         <mailto:herby at mailbox.sk>
>         <mailto: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>>
>         <mailto: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
>
>
> Of course, but again, I'm not sure how either of those would help
> identify which:
>
> '{ "foo": [1,2,3,4,5], "bar": [1,2,3,4,5] }'
>
> ...Is the Array and which is the Set
>
> Maybe I'm still misunderstanding? If I am, I apologize

The idea is that set is replaced with something like
	{ "this is an instance of Set": Array.from(aSet) }
and in the way back it is converted back to set again.
(so not a plain array, it is then not distiguishable, of course)
(similarly for maps etc.)

The problem is choosing how to transform there and back so it does not 
clash. If clash is avoided, using proper replacer in JSON.stringify and 
its counterpart in JSON.parse more-or-less-transparently JSON-encodes 
and -decodes sets.

>     (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).
>
>
> +1, this is something library authors should tackle before any language
> attention is given.
>
> Rick
>
>
>
>         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