Re: Array.prototype.contains

[Anne van Kesteren]

On Wed, Mar 5, 2014 at 11:19 PM, Domenic Denicola
 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

Re: Object.getOwnPropertyDescriptors(O) ? // plural

[Tom Van Cutsem]

2014-03-05 20:11 GMT+01:00 C. Scott Ananian :

> On Wed, Mar 5, 2014 at 1:39 PM, Tom Van Cutsem  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

[Mathias Bynens]

On 5 Mar 2014, at 17:19, Domenic Denicola  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: Functions as blocks

[Boris Zbarsky]

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: Functions as blocks

[Brendan Eich]

On Mar 5, 2014, at 6:53 PM, Allen Wirfs-Brock  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

[Allen Wirfs-Brock]

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

[Brendan Eich]

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

[John Barton]

On Wed, Mar 5, 2014 at 3:08 PM, Brian Terlson
wrote:

> 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

[Brian Terlson]

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

[Brendan Eich]

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

Functions as blocks

[Brian Terlson]

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: Object.getOwnPropertyDescriptors(O) ? // plural

[Andrea Giammarchi]

Thanks for clarification Tom, I've also added the main two _features_ this
method in the first gist I've posted but here a quick recap:

```javascript

// for shallow object copy
var shallowCopy = Object.create(
  Object.getPrototypeOf(origin),
  Object.getOwnPropertyDescriptors(origin)
);

// for traits / mixin
Object.defineProperties(
  target,
  Object.getOwnPropertyDescriptors(origin)
);

// respecting ES5 symmetry
Object.defineProperty(O, name, descriptor);
  descriptor as Object.getOwnPropertyDescriptor(O, name)


Object.defineProperties(O, descriptors);
  descriptors as Object.getOwnPropertyDescriptors(O)

```

Hope this one help presenting the what, the why, and the how.

Best Regards





On Wed, Mar 5, 2014 at 10:39 AM, Tom Van Cutsem  wrote:

> Object.getOwnPropertyDescriptors(obj) makes sense to me. As noted
> somewhere upstream, it's symmetrical to Object.defineProperties.
>
> When I designed traits.js, which was heavily based on property
> descriptors, I even added it to the library's public API, under the
> slightly shorter name Object.getOwnProperties(obj), cf. <
> http://traitsjs.org/api.html>
>
> Brendan asked me whether Object.getOwnPropertyDescriptors would
> necessitate a derived trap for proxies. I think the answer is no, just like
> Object.defineProperties(proxy) triggers just the proxy's
> getOwnPropertyNames trap, and then the defineProperty trap for each
> property, Object.getOwnPropertyDescriptors(proxy) would trigger the
> getOwnPropertyNames trap, followed by calls to the getOwnPropertyDescriptor
> trap for each individual property.
>
> Cheers,
> Tom
>
>
>
>
> 2014-03-05 1:38 GMT+01:00 Andrea Giammarchi :
>
>> You are right, I've realized it after posting ... `Object.assign(target,
>> source)` via `Get` and `Put` is basically the equivalent of a classic
>> `for/in` with `hasOwnProperty` check ... well, once again, in ES6
>> `Object.getOwnPropertyDescriptors(O)` seems to be a solution for other
>> cases too (shallow copy of properties, shallow clone, not just for/in) plus
>> yes, `Object.mixin(target, source)` might be simplified as well via this
>> proposal, that's a good point ... so 3 problems solved at once! :-)
>>
>>
>> On Tue, Mar 4, 2014 at 4:02 PM, Claude Pache wrote:
>>
>>>
>>>
>>> Le 5 mars 2014 à 00:18, Andrea Giammarchi 
>>> a écrit :
>>>
>>>
>>> Also please note that this proposal simplifies [Object.assign(target,
>>> source)](
>>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign)
>>> too since latter one is basically:
>>>
>>> ```javascript
>>> Object.defineProperties(
>>>   target,
>>>   Object.getOwnPropertyDescriptors(source)
>>> );
>>> ```
>>>
>>>
>>> No. `Object.assign` (1) uses the semantics of the assignment operator
>>> `=` (for example, it makes a difference in case of setters), and (2) copies
>>> only enumerable properties. Did you think about `Object.mixin`?
>>>
>>> --Claude
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[C. Scott Ananian]

Hmm:
```js
s = new Set(['a','b','c']);
s.has('a'); // true
s.has('ab'); // false

s = "abc";
s.contains("a"); // true
s.contains("ab"); // true
s.contains("ab", 1); // false

s = [ 'a', 'b', 'c' ];
s.has('a'); // true
s.has('ab'); // false

s.contains('a'); // true
s.contains('b', 1); // false? like String#contains
// what sebastian wants?
s.contains('a', 'b'); // true?
s.contains(...new Set(['a','b'])); // if the above works, so does this

s.has(...new Set(['a','b'])); // better?
```
 --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.getOwnPropertyDescriptors(O) ? // plural

[C. Scott Ananian]

On Wed, Mar 5, 2014 at 1:39 PM, Tom Van Cutsem  wrote:
> Object.getOwnPropertyDescriptors(proxy) would trigger the
> getOwnPropertyNames trap, followed by calls to the getOwnPropertyDescriptor
> trap for each individual property.

[[OwnPropertyKeys]], `ownKeys` trap.
  --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.getOwnPropertyDescriptors(O) ? // plural

[Tom Van Cutsem]

Object.getOwnPropertyDescriptors(obj) makes sense to me. As noted somewhere
upstream, it's symmetrical to Object.defineProperties.

When I designed traits.js, which was heavily based on property descriptors,
I even added it to the library's public API, under the slightly shorter
name Object.getOwnProperties(obj), cf. 

Brendan asked me whether Object.getOwnPropertyDescriptors would necessitate
a derived trap for proxies. I think the answer is no, just like
Object.defineProperties(proxy) triggers just the proxy's
getOwnPropertyNames trap, and then the defineProperty trap for each
property, Object.getOwnPropertyDescriptors(proxy) would trigger the
getOwnPropertyNames trap, followed by calls to the getOwnPropertyDescriptor
trap for each individual property.

Cheers,
Tom




2014-03-05 1:38 GMT+01:00 Andrea Giammarchi :

> You are right, I've realized it after posting ... `Object.assign(target,
> source)` via `Get` and `Put` is basically the equivalent of a classic
> `for/in` with `hasOwnProperty` check ... well, once again, in ES6
> `Object.getOwnPropertyDescriptors(O)` seems to be a solution for other
> cases too (shallow copy of properties, shallow clone, not just for/in) plus
> yes, `Object.mixin(target, source)` might be simplified as well via this
> proposal, that's a good point ... so 3 problems solved at once! :-)
>
>
> On Tue, Mar 4, 2014 at 4:02 PM, Claude Pache wrote:
>
>>
>>
>> Le 5 mars 2014 à 00:18, Andrea Giammarchi 
>> a écrit :
>>
>>
>> Also please note that this proposal simplifies [Object.assign(target,
>> source)](
>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign)
>> too since latter one is basically:
>>
>> ```javascript
>> Object.defineProperties(
>>   target,
>>   Object.getOwnPropertyDescriptors(source)
>> );
>> ```
>>
>>
>> No. `Object.assign` (1) uses the semantics of the assignment operator `=`
>> (for example, it makes a difference in case of setters), and (2) copies
>> only enumerable properties. Did you think about `Object.mixin`?
>>
>> --Claude
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Rick Waldron]

On Wed, Mar 5, 2014 at 11:19 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

>  Personally I think the more useful model to follow than
> `String.prototype.contains` is `Set.prototype.has`.
>
Now that you mention it, I completely agree.

Rick


>
>  --
> *From:* es-discuss  on behalf of Rick
> Waldron 
> *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.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

[Domenic Denicola]

Personally I think the more useful model to follow than 
`String.prototype.contains` is `Set.prototype.has`.



From: es-discuss  on behalf of Rick Waldron 

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 
mailto: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

[Rick Waldron]

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

[Rick Waldron]

On Wed, Mar 5, 2014 at 4:07 AM, David Bruant  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

[Boris Zbarsky]

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

[Sebastian Zartner]

>
>   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

[Eric Elliott]

According to the thread:

>* On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson >
*>* 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  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

[David Bruant]

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

Array.prototype.contains

[Eric Elliott]

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