Sets plus JSON

Rick Waldron waldron.rick at gmail.com
Wed Oct 3 11:13:48 PDT 2012


On Wed, Oct 3, 2012 at 2:07 PM, Herby Vojčík <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>> 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


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



> (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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121003/aee9173f/attachment-0001.html>


More information about the es-discuss mailing list