I don't think this makes sense. This has nothing to do with proxies:
js var o = Object.create(null)
js o +
typein:5: TypeError: can't convert o to primitive type
If there is no toString property, toString() on the object will fail.
This is not a new problem, even before ES5 this could break:
On Aug 25, 2011, at 7:56 AM, Mark S. Miller wrote:
[+es-discuss]
On Thu, Aug 25, 2011 at 2:40 AM, Cameron McCormack c...@mcc.id.au wrote:
+cc public-script-coord
-cc,+bcc public-device-apis
On 25/08/11 7:38 PM, Andreas Gal wrote:
We should take this to the WebIDL list then. The order
I really don't think IsProxy is a good idea. It can lead to subtle bugs
depending on whether an object is a DOM node, or a wrapper around a DOM node
(or whether the embedding uses a proxy to implement DOM nodes or not). In
Firefox we plan on making some DOM nodes proxies for example, but not
, David Bruant wrote:
And in general, the main use case for proxies is to emulate host objects. If
there is a language construct that helps separating the two cases, we're
going against this use case.
David
Le 13/07/2011 10:26, Andreas Gal a écrit :
I really don't think IsProxy is a good
There are various ways that implementation details can get exposed. For
example, by toString'ing a method property. I don't see why isProxy is any
more of an abstraction leak than toString. It is actually less, if we
clearly position it as one of the meta-programming functions that are
In our implementation we are using a generic object. It has some overhead, and
a specific internal descriptor object representation might be a bit faster,
but such magic objects that don't allow expando properties are usually pretty
surprising to programers. Most of the HTML5 DOM allows
Even if you want to store weak-map specific meta data per object, nobody would
store that directly in the object. Thats needlessly cruel on the cache since
99.9% of objects never end up in a weak map. Instead one would locate that
meta data outside the object in a direct mapped dense area
Can you describe those common use cases, and how they are impossible with the
current specification?
Andreas
On May 14, 2011, at 3:05 PM, Oliver Hunt wrote:
The more I read the WeakMap spec, the more it seems to prevent the common use
cases I know of. Could someone give a few examples of
.
Can you provide a use case where you have an object key as the usual
programming idiom?
--Oliver
On May 14, 2011, at 3:25 PM, Andreas Gal wrote:
Can you describe those common use cases, and how they are impossible with
the current specification?
Andreas
On May 14, 2011, at 3:05
was
raised by Andreas Gal (CC'ed). SpiderMonkey-related bug [2]
Actually we are still going back and forth on this. Proto-climbing might be the
wrong selector here. Can call a getter or setter seems to be the better
category, and that would be only get and set. get and set definitely do need
I think there is pretty broad consensus that this will affect the web. To what
extent is unclear. I would be willing to take our nightly testers for a test
drive for a couple days to see how badly things break if TC39 is leaning
towards making such a change. Before we do that maybe you want to
Why would you want to enumerate the keys in a weak map?
Andreas
On Apr 7, 2011, at 4:04 PM, Mikeal Rogers wrote:
Weak Maps seems to have superseded ephemeron tables.
They are non-enumerable, does this also exclude any call that gives you an
array of the current keys?
If this is the
There is a little twist to this. You can create a proxy that has separate
implementations of [[Call]] and [[Construct]], and by fixing it, it converts to
a regular functions. However, this regular function is different from any
other non-host function: it behaves different w.r.t. to f() and
Hi David,
What does exactly not be trapped mean? If you define a property on a proxy
object, the defineProperty trap of the handler is the only method with which
that operation can succeed. If defineProperty doesn't exist you want us to just
ignore the operation?
I think this approach has
Note that almost all implementations break for-in enumeration order for dense
arrays, for some definition of dense.
Example (firefox):
a = []
a[2] = 1
a[1] = 1
a[0] = 1
for (i in a) alert(i)
will alert 0, 1, 2 (in that order).
Now if you do
a[x] = 1
you get 0, 1, 2, x
However, if we start
I think there is too much fear of changing the semantics of for-in. Its
semantics is already rather fuzzy. Allowing meta-programmability of for-in
(instead of creating a new for-:) syntax doesn't create any additional
surprises or hazards for JS programmers.
1. We have already agreed on an
16 matches
Mail list logo
