On 2014/08/21 11:50:31, wingo wrote:
On 2014/08/21 11:25:09, rossberg wrote:
> Would it be better to
> add
> > an enumerator callback that returns symbols?
>
> Yes, we most likely don't want to filter in this function directly, but
> downstream where necessary. For the API, it may be best to have a
separate
> function to get symbol keys, very much like we have it JS-side.
Hm, I think either I don't understand you, or I'm not being precise. The
current SetNamedPropertyHandler API allows users to specify a callback to
enumerate string-named properties. I was proposing that maybe we should
add
an
additional callback to the new SetNamedPropertyHandler call; the new
callback
would return symbol-named properties. In that way we wouldn't have to
filter
anywhere; you just call the right functions. WDYT?
Ah, okay.
Hm, I'm not sure. It seems to me that the API should ultimately be
consistent in
the sense that either String and Symbol names are treated together
everywhere,
or they are separated everywhere (kind of like "properties" and "elements"
already). Just separating them in some places seems a bit odd from the user
perspective.
https://codereview.chromium.org/467013003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.