Follow-up: I updated
http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics with a
more precise specification of the default behavior of all derived traps.
This should also resolve the double-coercion issue with Object.keys.
In summary:
- for has, hasOwn and get it's easy to fall back
Very much appreciated. Given all the nasty mutability in JS, I think
for the non-normative JS implementations you also might want to note
that it assumes that nobody has hampered with the primordial Object
object.
/Andreas
On 14 July 2011 12:34, Tom Van Cutsem tomvc...@gmail.com wrote:
tampered, not hampered, of course...
On 14 July 2011 12:52, Andreas Rossberg rossb...@google.com wrote:
Very much appreciated. Given all the nasty mutability in JS, I think
for the non-normative JS implementations you also might want to note
that it assumes that nobody has hampered with the
2011/7/7 David Herman dher...@mozilla.com
2011/7/6 Andreas Rossberg rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the intent.
Unless they are private name
I'm not sure. I briefly checked the private names proposal
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects and I
think the detailed interaction with proxies still has to be fleshed out.
Sure, I'll be happy to work with you on this.
The proposal does mention: All
On Jul 8, 2011, at 7:17 AM, David Herman wrote:
The proposal does mention: All reflective operations that produce a
property name, when reflecting on a private name, produce the name’s .public
property instead of the name itself.
Would the same hold for reflective operations that consume
Sorry, yes. Too early in the morning for me. :)
Indeed, handler traps are exactly the place where the system *produces* names
and hands them to handler traps which consume them, and that's where it must
produce a public key rather than a private name object.
Dave
On Jul 8, 2011, at 8:20 AM,
And just to be clear, I meant produce in the sense of producer/consumer
relationship on the trap functions, not in the generative sense.
Dave
On Jul 8, 2011, at 8:40 AM, David Herman wrote:
Sorry, yes. Too early in the morning for me. :)
Indeed, handler traps are exactly the place where
Le 07/07/2011 13:11, Tom Van Cutsem a écrit :
2011/7/6 Andreas Rossberg rossb...@google.com
mailto:rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the
On 7 July 2011 13:11, Tom Van Cutsem tomvc...@gmail.com wrote:
2011/7/6 Andreas Rossberg rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the intent.
It seems
Le 07/07/2011 14:29, Andreas Rossberg a écrit :
On 7 July 2011 13:11, Tom Van Cutsemtomvc...@gmail.com wrote:
2011/7/6 Andreas Rossbergrossb...@google.com
It seems like a reasonable assumption, but is not currently the case
everywhere (e.g. the default implementation for `keys' can violate
On 7 July 2011 14:32, David Bruant david.bru...@labri.fr wrote:
However, if we assume that the getOwnPropertyNames trap is able to do type
coercion on its output, there is no reason for the keys trap to not do that
too, regardless of how it was implemented.
Yes, that's what I would propose,
Le 07/07/2011 14:40, Andreas Rossberg a écrit :
On 7 July 2011 14:32, David Bruantdavid.bru...@labri.fr wrote:
However, if we assume that the getOwnPropertyNames trap is able to do type
coercion on its output, there is no reason for the keys trap to not do that
too, regardless of how it was
On 7 July 2011 15:09, David Bruant david.bru...@labri.fr wrote:
Yes, that's what I would propose, too. It's just a bit ugly that we
have to do that in two places now.
Three if counting the enumerate trap for for-in loops. Regardless of
ugliness, it's necessary. keys and enumerate are derived
2011/7/6 Andreas Rossberg rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the intent.
Unless they are private name objects, right?
Dave
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Engines
will be free to optimize as they wish internally as long as the observed
behavior is the same.
True, but optimizing that actually is more tricky than you
On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote:
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Engines
will be free to optimize as they wish internally as long as the observed
behavior is the same.
On 7 July 2011 17:58, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote:
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Engines
will be free to optimize as they wish
Le 07/07/2011 18:05, Andreas Rossberg a écrit :
On 7 July 2011 17:58, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote:
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Le 07/07/2011 18:24, David Bruant a écrit :
Le 07/07/2011 18:05, Andreas Rossberg a écrit :
On 7 July 2011 17:58, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote:
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as
On 7 July 2011 19:35, David Bruant david.bru...@labri.fr wrote:
No, with the current keys default trap (calling
this.getOwnPropertyNames()) there is no double conversion. Only one at
the exit of the keys trap. There would be 2 conversions if the keys
trap had the proxy argument (based on
Le 07/07/2011 20:52, Andreas Rossberg a écrit :
On 7 July 2011 19:35, David Bruant david.bru...@labri.fr wrote:
No, with the current keys default trap (calling
this.getOwnPropertyNames()) there is no double conversion. Only one at
the exit of the keys trap. There would be 2 conversions if the
22 matches
Mail list logo
