Array.prototype.contains
What ever happened to Array.prototype.contains? There's an old strawman for Array.prototype.has ( http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has ) that references this thread: ( https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html ) But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM. It's also a standard utility function in several libraries. Was it left out on purpose? If so, what was the justification? I predict code like this without it: ''.contains.call([1, 2, 3], 2); // true - Eric Author, Programming JavaScript Applications (O'Reilly) http://ericleads.com/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
Le 05/03/2014 09:24, Eric Elliott a écrit : What ever happened to Array.prototype.contains? There's an old strawman for Array.prototype.has ( http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has ) that references this thread: ( https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html ) Let's try to add it to the next meeting agenda https://github.com/tc39/agendas/pull/27 But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM. The DOM won't inherit from it directly, shall it? It's also a standard utility function in several libraries. Was it left out on purpose? If so, what was the justification? I predict code like this without it: ''.contains.call([1,2,3],2);// true .indexOf === -1 works today for this use case and will continue to. I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
According to the thread: * On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson erik.arvidsson at gmail.com https://mail.mozilla.org/listinfo/es-discuss ** wrote:* * DOM4 added a new interface called DOMStringList for the sole reason ** that Array does not have contains. Before this the return type was an ** Array of Strings so we could use indexOf, map, forEach etc. Now that ** it is using a non Array we lost all of that. *We (WebKit) used to return a true JS Array (created by JSC or V8). Author, Programming JavaScript Applications (O'Reilly) http://ericleads.com/ On Wed, Mar 5, 2014 at 2:07 AM, David Bruant bruan...@gmail.com wrote: Le 05/03/2014 09:24, Eric Elliott a écrit : What ever happened to Array.prototype.contains? There's an old strawman for Array.prototype.has ( http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has ) that references this thread: ( https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html ) Let's try to add it to the next meeting agenda https://github.com/tc39/agendas/pull/27 But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM. The DOM won't inherit from it directly, shall it? It's also a standard utility function in several libraries. Was it left out on purpose? If so, what was the justification? I predict code like this without it: ''.contains.call([1, 2, 3], 2); // true .indexOf === -1 works today for this use case and will continue to. I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM. The DOM won't inherit from it directly, shall it? Why not? A use case would be to check whether a specific node is within a NodeList. It's also a standard utility function in several libraries. Was it left out on purpose? If so, what was the justification? I predict code like this without it: ''.contains.call([1, 2, 3], 2); // true .indexOf === -1 works today for this use case and will continue to. I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though. While .indexOf() just gets you the index of one item, .contains() could even be extended to allow to check whether an array contains several items. E.g. .contains([1, 2, 3], [1, 3]) // true .contains([1, 2, 3], [1, 4]) // false Sebastian ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
On 3/5/14 7:04 AM, Sebastian Zartner wrote: Why not? A use case would be to check whether a specific node is within a NodeList. NodeLists don't have have Array.prototype on their proto chain in browsers at the moment, and might never get there; there are compat concerns. I'd love to get rid of DOMStringList, though. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
On Wed, Mar 5, 2014 at 4:07 AM, David Bruant bruan...@gmail.com wrote: Le 05/03/2014 09:24, Eric Elliott a écrit : What ever happened to Array.prototype.contains? There's an old strawman for Array.prototype.has ( http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has ) that references this thread: ( https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html ) Let's try to add it to the next meeting agenda https://github.com/tc39/agendas/pull/27 But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM. The DOM won't inherit from it directly, shall it? The forth-coming-still-in-design Elements class will inherit from Array. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
On Wed, Mar 5, 2014 at 7:04 AM, Sebastian Zartner sebastianzart...@gmail.com wrote: But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM. The DOM won't inherit from it directly, shall it? Why not? A use case would be to check whether a specific node is within a NodeList. It's also a standard utility function in several libraries. Was it left out on purpose? If so, what was the justification? I predict code like this without it: ''.contains.call([1, 2, 3], 2); // true .indexOf === -1 works today for this use case and will continue to. I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though. While .indexOf() just gets you the index of one item, .contains() could even be extended to allow to check whether an array contains several items. E.g. .contains([1, 2, 3], [1, 3]) // true .contains([1, 2, 3], [1, 4]) // false String.prototype.contains already has a second parameter for position (similar to String.prototype.indexOf), for consistency an Array.prototype.contains should have the same second fromIndex parameter as Array.prototype.indexOf. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Array.prototype.contains
Personally I think the more useful model to follow than `String.prototype.contains` is `Set.prototype.has`. From: es-discuss es-discuss-boun...@mozilla.org on behalf of Rick Waldron waldron.r...@gmail.com Sent: Wednesday, March 05, 2014 11:11 To: Sebastian Zartner Cc: es-discuss Subject: Re: Array.prototype.contains On Wed, Mar 5, 2014 at 7:04 AM, Sebastian Zartner sebastianzart...@gmail.commailto:sebastianzart...@gmail.com wrote: But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM. The DOM won't inherit from it directly, shall it? Why not? A use case would be to check whether a specific node is within a NodeList. It's also a standard utility function in several libraries. Was it left out on purpose? If so, what was the justification? I predict code like this without it: ''.contains.call([1, 2, 3], 2); // true .indexOf === -1 works today for this use case and will continue to. I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though. While .indexOf() just gets you the index of one item, .contains() could even be extended to allow to check whether an array contains several items. E.g. .contains([1, 2, 3], [1, 3]) // true .contains([1, 2, 3], [1, 4]) // false String.prototype.contains already has a second parameter for position (similar to String.prototype.indexOf), for consistency an Array.prototype.contains should have the same second fromIndex parameter as Array.prototype.indexOf. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Functions as blocks
We have discussed, at length, the various ways in which browsers differ in
their handling of functions-in-blocks:
```js
if(test) {
function foo() { }
}
```
At the last TC-39 we approved semantics for block-scoped functions in sloppy
mode. We did not discuss directly, that I recall, how the following should be
handled:
```js
if(test) function foo() { }
```
Per spec I believe this is a syntax error, but all browsers seem to allow it
(with minor differences in semantics similar to function-in-block scenarios).
Are implementers going to be making this an error or carrying forward this
extension? If carrying forward, are there any objections to adding this
extension to Annex B with minimal intersection semantics similar to F-I-B?
I haven't collected much data on this so I'm not sure what the prevalence is,
but we'd err on the side of caution and continue supporting it unless other
implementers are confident enough to remove it. If no one will be removing it,
it makes sense to me to add this to Annex B. Eager to hear what others'
thoughts are.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Functions as blocks
Brian Terlson wrote: I haven't collected much data on this so I'm not sure what the prevalence is, Can you try to find some sightings in the wild? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Functions as blocks
Brendan Eich wrote: Brian Terlson wrote: I haven't collected much data on this so I'm not sure what the prevalence is, Can you try to find some sightings in the wild? I have searched my Alexa Top 10k dataset and didn't find any occurrences. The dataset has the same limitations as before - only front page load, no dynamic scripts - with the added problem of now being ~1.5yrs old. I'm not sure how much the absence of this pattern tells us. My thinking is that instrumenting some runtime and browsing/crawling the web would give us the data to feel confident about dropping this feature. Unfortunately that isn't an option available to me to try at the moment... Open to other suggestions, though! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Functions as blocks
On Wed, Mar 5, 2014 at 3:08 PM, Brian Terlson brian.terl...@microsoft.comwrote: Brendan Eich wrote: Brian Terlson wrote: I haven't collected much data on this so I'm not sure what the prevalence is, Can you try to find some sightings in the wild? I have searched my Alexa Top 10k dataset and didn't find any occurrences. The dataset has the same limitations as before - only front page load, no dynamic scripts - with the added problem of now being ~1.5yrs old. I'm not sure how much the absence of this pattern tells us. The biggest problem with this test is that the Alexa set selects for sites with experienced developers writing for production sites. The pattern you are trying to detect is not used in these circumstances. My thinking is that instrumenting some runtime and browsing/crawling the web would give us the data to feel confident about dropping this feature. Unfortunately that isn't an option available to me to try at the moment... Open to other suggestions, though! As you say all browsers seem to allow it. Browsers made the mistake and we should not go back now and blame developers on smaller sites because they use this kind of code. Make it a syntax error in modules and save yourself a lot of headaches. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Functions as blocks
John Barton wrote:
As you say all browsers seem to allow it. Browsers made the mistake
and we should not go back now and blame developers on smaller sites
because they use this kind of code. Make it a syntax error in modules
and save yourself a lot of headaches.
We could do this for sure, and in the absence of evidence that if (x)
function y(){} is used in the wild, we should. With such evidence, we
should. So, we should ;-).
But there's more to consider. IIRC, originally KJS (pre-JSC) in WebKit
did not support function-in-block or function-in-unbraced-consequent.
Then they added function-in-block support, bowing to the well-known uses
on the Web. When did they add function-in-unbraced, and why? Perhaps
someone can cite the fixed webkit.org bug.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Functions as blocks
On Mar 5, 2014, at 6:23 PM, Brendan Eich wrote:
John Barton wrote:
As you say all browsers seem to allow it. Browsers made the mistake and we
should not go back now and blame developers on smaller sites because they
use this kind of code. Make it a syntax error in modules and save yourself a
lot of headaches.
We could do this for sure, and in the absence of evidence that if (x)
function y(){} is used in the wild, we should. With such evidence, we should.
So, we should ;-).
But there's more to consider. IIRC, originally KJS (pre-JSC) in WebKit did
not support function-in-block or function-in-unbraced-consequent. Then they
added function-in-block support, bowing to the well-known uses on the Web.
When did they add function-in-unbraced, and why? Perhaps someone can cite the
fixed webkit.org bug.
We would have to come up with an an appropriate intersection semantics and we
don't have a base ES semantics to work off of as a function declaration is
illegal in that posiion in ES6. Would we also have to accommodate it for
IterationStatements and WithStatement
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Functions as blocks
On Mar 5, 2014, at 6:53 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 5, 2014, at 6:23 PM, Brendan Eich wrote:
John Barton wrote:
As you say all browsers seem to allow it. Browsers made the mistake and
we should not go back now and blame developers on smaller sites because
they use this kind of code. Make it a syntax error in modules and save
yourself a lot of headaches.
We could do this for sure, and in the absence of evidence that if (x)
function y(){} is used in the wild, we should. With such evidence, we
should. So, we should ;-).
But there's more to consider. IIRC, originally KJS (pre-JSC) in WebKit did
not support function-in-block or function-in-unbraced-consequent. Then they
added function-in-block support, bowing to the well-known uses on the Web.
When did they add function-in-unbraced, and why? Perhaps someone can cite
the fixed webkit.org bug.
We would have to come up with an an appropriate intersection semantics and we
don't have a base ES semantics to work off of as a function declaration is
illegal in that posiion in ES6. Would we also have to accommodate it for
IterationStatements and WithStatement
Right, it is not free - nothing around here is!
The other way to go optimizes for the reason WebKit folks added unbraced
support no longer applying: leave draft ES6 as is, implement and test among
major browsers, and see what comes out in the wash.
If no one else looks, I will try to find the WebKit.org bug trail.
/be
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Functions as blocks
On 3/5/14 4:26 PM, Brian Terlson wrote: I haven't collected much data on this so I'm not sure what the prevalence is Given the number of stackoverflow posts I've seen that come down to browsers not being exactly compatible on their handling of this code, its prevalence is too high to allow us to remove the behavior in simple cases. :( -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
On 5 Mar 2014, at 17:19, Domenic Denicola dome...@domenicdenicola.com wrote: Personally I think the more useful model to follow than `String.prototype.contains` is `Set.prototype.has`. But then DOM4 `DOMStringList` would still have its own `contains` _and_ the `has` it inherits from `Array.prototype`. That seems confusing, no? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptors(O) ? // plural
2014-03-05 20:11 GMT+01:00 C. Scott Ananian ecmascr...@cscott.net: On Wed, Mar 5, 2014 at 1:39 PM, Tom Van Cutsem tomvc...@gmail.com wrote: Object.getOwnPropertyDescriptors(proxy) would trigger the getOwnPropertyNames trap, followed by calls to the getOwnPropertyDescriptor trap for each individual property. [[OwnPropertyKeys]], `ownKeys` trap. Yes, according to the current draft spec. I have a pending discussion with Allen that we actually need to reintroduce a [[GetOwnPropertyNames]] internal method / getOwnPropertyNames trap, as the `ownKeys` trap doesn't do any invariant checking, which is needed for a reliable Object.isFrozen test. Regards, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
On Wed, Mar 5, 2014 at 11:19 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Personally I think the more useful model to follow than `String.prototype.contains` is `Set.prototype.has`. That would not allow us to kill DOMStringList. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
