On Nov 16, 2014, at 11:08 PM, Tom Van Cutsem wrote:
2014-11-17 3:34 GMT+01:00 Frankie Bagnardi f.bagna...@gmail.com:
Consider when Array.isArray would be used. In my experience, checks to see
if something is an array are used for:
- deciding how to iterate it (for(;;) vs for..in, for
Allen Wirfs-Brock wrote:
```js
Array[Symbol.isArray]] = true; //note, this is a constructor
property, not an Array.prototype property.
Minomer, then -- how about Symbol.isArrayClass?
we also change Array.prototype.concat to do the above Array.isArray
test instead of using
On Nov 17, 2014, at 11:06 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
```js
Array[Symbol.isArray]] = true; //note, this is a constructor property, not
an Array.prototype property.
Minomer, then -- how about Symbol.isArrayClass?
perhaps, I have a negative reaction to including the
On Nov 17, 2014, at 2:30 PM, Allen Wirfs-Brock wrote:
On Nov 17, 2014, at 11:06 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
```js
Array[Symbol.isArray]] = true; //note, this is a constructor property, not
an Array.prototype property.
Minomer, then -- how about
Allen Wirfs-Brock wrote:
if (isProxy(obj)) return isArray(getProxyTarget(obj));
//Array.isArray(new Proxy(Object.create(Array.prototype), {}))
//I'm not sure that the above line is really a compat. issue. I'd
prefer to leave it out.
Please do -- it contradicts the righteous
2014-11-17 18:30 GMT+01:00 Allen Wirfs-Brock al...@wirfs-brock.com:
But probing through the proxy as has been proposed is a terrible violation
of the MOP API boundary and isn't generalizable to other built-ins that are
dependent upon internal state. While a null handler proxy on a direct
On 11/16/14, 2:12 AM, Brendan Eich wrote:
Are you confident this change is web-compatible?
No, I said that up-thread already. So there may be nothing to worry
about here spec-wise for now.
-Boris
___
es-discuss mailing list
Consider when Array.isArray would be used. In my experience, checks to see
if something is an array are used for:
- deciding how to iterate it (for(;;) vs for..in, for example)
- deciding if the output should be an array or plain object (e.g. lodash)
- early errors, e.g. runtime typecheck
2014-11-17 3:34 GMT+01:00 Frankie Bagnardi f.bagna...@gmail.com:
Consider when Array.isArray would be used. In my experience, checks to
see if something is an array are used for:
- deciding how to iterate it (for(;;) vs for..in, for example)
This is a good one. Here, again, a typical
Le 13/11/2014 17:29, Boris Zbarsky a écrit :
On 11/13/14, 6:44 AM, Andreas Rossberg wrote:
Well, the actual diabolic beast and universal foot gun in this example
is setPrototypeOf. ;)
Note that there is at least some discussion within Mozilla about
trying to make the prototype of
On Nov 15, 2014, at 1:24 AM, David Bruant wrote:
Le 13/11/2014 17:29, Boris Zbarsky a écrit :
On 11/13/14, 6:44 AM, Andreas Rossberg wrote:
Well, the actual diabolic beast and universal foot gun in this example
is setPrototypeOf. ;)
Note that there is at least some discussion within
On 11/15/14, 11:47 AM, Allen Wirfs-Brock wrote:
Actually the ES6 semantics does allow for this. The global object would have t
be implemented as a new kind of implementation specific exotic object whose
[[SetPrototypeOf]] internal method always returns false.
That works for the global
Boris Zbarsky wrote:
On 11/15/14, 11:47 AM, Allen Wirfs-Brock wrote:
- hide quoted text -- show quoted text -
Actually the ES6 semantics does allow for this. The global object
would have t be implemented as a new kind of implementation specific
exotic object whose [[SetPrototypeOf]] internal
As quick parenthesis, I do hope the potentially evil code I've written will
be possible in the future, as universal solution to `undefined is not
defined` error in development code.
evil is never necessarily evil, going with prohibitionism won't make
anyone happy.
About `Array.isArray` though, I
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Tom Van
Cutsem
Is the `length` invariant really the dominant meaning JS developers attribute
to Array.isArray? I think to most developers Array.isArray(obj) returning
true means that it's safe to call the array utilities
Hai.
Why not Symbol.isArray?
To me the most interesting question is how to create objects that get
JSON-stringified as [], not {}. Some sort of symbol-based mechanism makes
sense for that, IMO...
toJSON method.
`JSON.stringify({toJSON: () = [2,3,4,5]})`
This is really interesting. It does argue for some kind of redefinition of
Array.isArray to return is this an instance of some %ArrayPrototype% in
some realm?
Yeah, my guess would be that if (Array.isArray(obj) === true), then the
user will infer that one or both of the following is true:
-
On Nov 13, 2014, at 5:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
We might redefine Array.isArray to be based upon testing for
@@isConcatSpreadable but that potentially would give different results for
legacy uses that did __proto__ hacking such as I mentioned in my previous
On Nov 14, 2014, at 4:53 AM, Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Tom Van
Cutsem
Is the `length` invariant really the dominant meaning JS developers
attribute to Array.isArray? I think to most developers Array.isArray(obj)
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
What do you mean by is an instance of some %ArrayPrototype%? Do you mean
that it has some %ArratPrototype% in it's prototype chain?
Yeah, more or less. A realm-independent instanceof. This makes sense also
from the historical
On Nov 14, 2014, at 11:41 AM, Domenic Denicola wrote:
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
What do you mean by is an instance of some %ArrayPrototype%? Do you mean
that it has some %ArratPrototype% in it's prototype chain?
Yeah, more or less. A realm-independent
2014-11-14 21:00 GMT+01:00 Allen Wirfs-Brock al...@wirfs-brock.com:
On Nov 14, 2014, at 11:41 AM, Domenic Denicola wrote:
Yeah, more or less. A realm-independent instanceof. This makes sense
also from the historical perspective that `Array.isArray` was meant to
provide a cross-realm
Tom Van Cutsem wrote:
No really, it was a way to expose a test of the [[Class]] internal
property. That test wasn't dependent upon the [[Prototype]] chain.
I think what Domenic was saying is that Array.isArray used such a test
*because* instanceof Array didn't work reliably
2014-11-13 22:35 GMT+01:00 Tom Van Cutsem tomvc...@gmail.com:
My intuition is that Array.isArray is often used to branch based on
whether code received just one versus a collection of values. E.g. a
function may take a single parameter that can be bound to either a single
value or a
I don't have the data to back this up, but I would argue that the developer
community has essentially adopted `Array.isArray()` as a sane replacement
for `Object.prototype.toString.call(maybeArray) === '[object Array]'`.
I realize this forum doesn't have the luxury of *not* considering the
2014-11-14 21:52 GMT+01:00 Jeremy Martin jmar...@gmail.com:
Allen's previous comments:
Proxies are not transparent forwarders! In particular their default
handling of the `this` value on method invokes will break any built-in
method that needs to access internal slots of an object.
Tom Van Cutsem wrote:
2014-11-14 21:52 GMT+01:00 Jeremy Martin jmar...@gmail.com
mailto:jmar...@gmail.com:
Allen's previous comments:
Proxies are not transparent forwarders! In particular their
default handling of the `this` value on method invokes will
break any
(Mostly) transparent forwarding seems to be one of the more compelling and
generally useful characteristics of Proxies. I have to lean heavily on the
deeper knowledge of the group here, but *if* `new Proxy([], {})` otherwise
behaves like a bonafide array when you treat it like one, then it would
well, Proxy can be a diabolic beast
```js
Object.setPrototypeOf(
Object.prototype,
new Proxy(Object.prototype, evilPlan)
)
```
having no way to understand if an object is a Proxy looks like a footgun to
me in the long term, for libraries, and code alchemists
You indeed wrote that different
On 13 November 2014 12:25, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
well, Proxy can be a diabolic beast
```js
Object.setPrototypeOf(
Object.prototype,
new Proxy(Object.prototype, evilPlan)
)
```
having no way to understand if an object is a Proxy looks like a footgun to
Same would be reassigning any prototype but it was just to make the
diabolic point... also yeah, sPO is powerful, that's why we love it!
( it's also way less diabolic than any __proto__ string floating around
;) )
On Thu, Nov 13, 2014 at 11:44 AM, Andreas Rossberg rossb...@google.com
wrote:
On
The best defense is Object.freeze(Object.prototype);
No application worth considering needs to arbitrarily modify
Object.prototype at an arbitrary point in time (or someone should bring
a use case for discussion). It usually shouldn't and even if it does, it
should do it at startup and freeze
On 11/13/14, 6:44 AM, Andreas Rossberg wrote:
Well, the actual diabolic beast and universal foot gun in this example
is setPrototypeOf. ;)
Note that there is at least some discussion within Mozilla about trying
to make the prototype of Object.prototype immutable (such that
On Nov 12, 2014, at 12:12 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-11-12 19:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com:
I agree and I want to know if you think this is worth revisiting once more?
Next meeting's agenda?
I don't think we've ever discussed this issue before
On Nov 12, 2014, at 11:58 AM, Jeremy Martin wrote:
My opinion is that array testing is fundamental to core JS and is worth the
exception.
Knowing that Array.isArray() tests fail for proxies, I'd be afraid to ever
create a Proxy for an array that I don't control the complete lifecycle of.
2014-11-13 20:31 GMT+01:00 Allen Wirfs-Brock al...@wirfs-brock.com:
3) Proxies. Should Array.isArray treat proxy instances specially? To
answer this question we need to think about what a ES programmer actually
thinks Array.isArray means? The meaning that ES5 established is that
Allen Wirfs-Brock wrote:
We might redefine Array.isArray to be based upon testing for
@@isConcatSpreadable but that potentially would give different results
for legacy uses that did __proto__ hacking such as I mentioned in my
previous mote.
How about we turn the @@ property into
The subject is a SpiderMonkey bug.
Is that really desirable? Doesn’t it invalidate the Proxy’s role as an
interceptor?
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
I agree with your sentiment. I have previously advocated that Array.isArray
should be transparent for proxies. My harmony-reflect shim explicitly
differs from the spec on this point because people using the shim
spontaneously reported this as the expected behaviour and thought it was a
bug that
Le 12/11/2014 17:23, Tom Van Cutsem a écrit :
I agree with your sentiment. I have previously advocated that
Array.isArray should be transparent for proxies. My harmony-reflect
shim explicitly differs from the spec on this point because people
using the shim spontaneously reported this as the
On Wed, Nov 12, 2014 at 11:23 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
My opinion is that array testing is fundamental to core JS and is worth
the exception.
I agree and I want to know if you think this is worth revisiting once more?
Next meeting's agenda?
Rick
2014-11-12 19:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com:
I agree and I want to know if you think this is worth revisiting once
more? Next meeting's agenda?
I don't think we've ever discussed this issue before during a TC39 meeting
(but I didn't attend quite a few, so I may be wrong).
In general, it appears that SM unwraps proxies so that internal slot access
is transparently forwarded. I don't see any such unwrapping in the ES spec
though. I assume that the spec is correct?
___
es-discuss mailing list
es-discuss@mozilla.org
On Wed, Nov 12, 2014 at 2:12 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-11-12 19:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com:
I agree and I want to know if you think this is worth revisiting once
more? Next meeting's agenda?
I don't think we've ever discussed this issue before
My opinion is that array testing is fundamental to core JS and is worth
the exception.
Knowing that Array.isArray() tests fail for proxies, I'd be afraid to ever
create a Proxy for an array that I don't control the complete lifecycle of.
That seems to critically inhibit the usefulness of
If Array.isArray should fail for non pure Arrays, can we have a
Proxy.isProxy that never fails with proxies ?
At least this would give a better idea on what's eventually going on:
```js
if (Array.isArray(obj) !Proxy.isProxy(obj)) {
// ... ok, pure Array, no magic wrappers
}
```
Regards
On
2014-11-12 20:37 GMT+01:00 Kevin Smith zenpars...@gmail.com:
In general, it appears that SM unwraps proxies so that internal slot
access is transparently forwarded. I don't see any such unwrapping in the
ES spec though. I assume that the spec is correct?
This auto-unwrapping for internal
2014-11-12 23:49 GMT+01:00 Andrea Giammarchi andrea.giammar...@gmail.com:
If Array.isArray should fail for non pure Arrays, can we have a
Proxy.isProxy that never fails with proxies ?
We ruled out `Proxy.isProxy` very early on in the design. It's antithetical
to the desire of keeping proxies
On 12 November 2014 17:23, Tom Van Cutsem tomvc...@gmail.com wrote:
My opinion is that array testing is fundamental to core JS and is
worth the exception.
This change would only make sense if we also were to special-case all
other places in the spec that currently say if O is an exotic Array
2014-11-12 20:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com:
Done https://github.com/tc39/agendas/blob/master/2014/11.md
Thanks. A related point: my harmony-reflect shim also patches
Array.prototype.concat such that it recognizes proxies-for-arrays and will
splice their elements (rather
2014-11-13 8:18 GMT+01:00 Andreas Rossberg rossb...@google.com:
On 12 November 2014 17:23, Tom Van Cutsem tomvc...@gmail.com wrote:
My opinion is that array testing is fundamental to core JS and is
worth the exception.
This change would only make sense if we also were to special-case all
51 matches
Mail list logo
