Rick Waldron wrote:
On Wed, Oct 3, 2012 at 2:07 PM, Herby Vojčík <he...@mailbox.sk
<mailto:he...@mailbox.sk>> wrote:
Rick Waldron wrote:
On Wed, Oct 3, 2012 at 1:57 PM, Herby Vojčík <he...@mailbox.sk
<mailto:he...@mailbox.sk>
<mailto:he...@mailbox.sk <mailto:he...@mailbox.sk>>> wrote:
Rick Waldron wrote:
On Wed, Oct 3, 2012 at 12:56 PM, Herby Vojčík
<he...@mailbox.sk <mailto:he...@mailbox.sk>
<mailto:he...@mailbox.sk <mailto:he...@mailbox.sk>>
<mailto:he...@mailbox.sk <mailto:he...@mailbox.sk>
<mailto:he...@mailbox.sk <mailto:he...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
