Re: Array.prototype.contains solutions

> > > https://www.google.com/search?q=site%3Aesdiscuss.org+Array.prototype.contains+solutions > leads to https://esdiscuss.org/topic/array-prototype-contains-solutions > which is probably what you were thinking of. > > They were not very good ideas. > For some reason I thought you had evolved thos

Re: Array.prototype.contains solutions

Domenic Denicola wrote: https://www.google.com/search?q=site%3Aesdiscuss.org+Array.prototype.contains+solutions leads tohttps://esdiscuss.org/topic/array-prototype-contains-solutions which is probably what you were thinking of. They were not very good ideas. It's a hard problem. Original-J

RE: Array.prototype.contains solutions

https://www.google.com/search?q=site%3Aesdiscuss.org+Array.prototype.contains+solutions leads to https://esdiscuss.org/topic/array-prototype-contains-solutions which is probably what you were thinking of. They were not very good ideas. ___ es-discuss

Re: Array.prototype.contains solutions

I faintly remember seeing a sort of "proposal" containing many different approaches as how to solve this generic built-ins extensions problem in future editions of ECMAScript. I believe it was authored by Domenic Denicola, in Gist/GitHub format if memory serves me right. I can't seem to find it, d

Re: Array.prototype.contains solutions

Jason Orendorff wrote: I'd love to be able to get rid of SHADOWABLE, actually! I just recently found out we can do it with a little rearranging. Extra state-space in property attributes is unavoidable complexity for us. My own preference would be not to standardize it.:) There's also the [Replac

Re: Array.prototype.contains solutions

I'd love to be able to get rid of SHADOWABLE, actually! I just recently found out we can do it with a little rearranging. Extra state-space in property attributes is unavoidable complexity for us. My own preference would be not to standardize it. :) There's also the [Replaceable] attribute in WebI

Re: Array.prototype.contains solutions

Mark S. Miller wrote: Does the [[Overridable]] you have in mind also fix the override mistake? It sounds like it should. Yes, definitely. Regarding shadowable, is there any better documentation than the doc-comment: |/*| | * For ES5 compatibility, we allow properties with PropertyOp-fl

Re: Array.prototype.contains solutions

Does the [[Overridable]] you have in mind also fix the override mistake? It sounds like it should. Regarding shadowable, is there any better documentation than the doc-comment: /* * For ES5 compatibility, we allow properties with PropertyOp-flavored * setters to be shadowed when set. The

Re: Array.prototype.contains solutions

Claude Pache wrote: The more I consider the issue, the more I think that the most elegant solution is to complete data properties with an additional "overridable" attribute, whose purpose is to refine the meaning of the "writable" attribute in the manner sketched below (in opposition of having

Re: Array.prototype.contains solutions

On Wed, Oct 1, 2014 at 12:21 AM, Brendan Eich wrote: > > The most painful use case is the existence of perfectly reasonable ES5 >> code like: >> >> >> function Point(x, y) { this.x = x; this.y = y; } >> >> Point.prototype.toString() { return `<${x},${y}>`; }; >> > > You mean > > Poin

RE: Array.prototype.contains solutions

small enough already. Regards -Original Message- From: "Brendan Eich" Sent: ‎01/‎10/‎2014 09:23 To: "Andrea Giammarchi" Cc: "Mark S. Miller" ; "es-discuss@mozilla.org" Subject: Re: Array.prototype.contains solutions Andrea Giammarchi wrote: > 1.

Re: Array.prototype.contains solutions

er problem, it does > not pay its own way just for Array.prototype.contains (and potentially > Array.prototype.flatten). > > > From: Claude Pache [mailto:claude.pa...@gmail.com] > Sent: Wednesday, October 1, 2014 09:36 > To: Mark S. Miller > Cc: Domenic Denicola;

RE: Array.prototype.contains solutions

scuss@mozilla.org Subject: Re: Array.prototype.contains solutions Le 1 oct. 2014 à 04:43, Mark S. Miller mailto:erig...@google.com>> a écrit : I suggest we focus on the override mistake. If we come up with a way of fixing it and .contains with one new kernel mechanism, that would be great.

Re: Array.prototype.contains solutions

Le 1 oct. 2014 à 04:43, Mark S. Miller a écrit : > > I suggest we focus on the override mistake. If we come up with a way of > fixing it and .contains with one new kernel mechanism, that would be great. > If we only fix the override mistake, still likely worth it. But if a new > kernel mecha

Re: Array.prototype.contains solutions

Andrea Giammarchi wrote: 1. I wasn't advocating to break the web but to **not** change the name because of a library bug, the initial thread spoiler was not needed I wasn't responding to you, here on this thread (where you hadn't posted till now) or on the other one, so why are you jumping i

Re: Array.prototype.contains solutions

1. I wasn't advocating to break the web but to **not** change the name because of a library bug, the initial thread spoiler was not needed 2. the `@@enumerableWhenAssigned` might lead to shenanigans but it's *polyfillable* which is IMO preferable if it can solve somehow the problem ```js enum

Re: Array.prototype.contains solutions

Mark S. Miller wrote: On Tue, Sep 30, 2014 at 4:58 PM, Domenic Denicola mailto:dome...@domenicdenicola.com>> wrote: I see a few options: 1. Rename. The leading candidate would be `Array.prototype.has`. I outlined in [1] why `contains` is better; note especially the DOM classes.

Re: Array.prototype.contains solutions

On Tue, Sep 30, 2014 at 4:58 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > This is a follow-up thread to discuss how to solve the problem identified > in > http://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web-compatible > without breaking the we

Re: Array.prototype.contains solutions

Maybe. Though there would still be issues with implementations not aligning, like Ember which does use defineProperty to make them non-enumerable and doesn't pave existing methods, as well as issues with scripts that support pre-ES5 environments that don't want enumerable inconsistency. JDD On T

Re: Array.prototype.contains solutions

On 9/30/14, 8:12 PM, John-David Dalton wrote: Extending native prototypes is a JavaScript "thing" and something that will most likely continue continue. Note that if people were extending in nice ways, using defineProperty and making their props non-enumerable instead of just doing a [[Set]],

Re: Array.prototype.contains solutions

A more general solution seems like a good idea. Renaming doesn't really solve the deeper issue. Extending native prototypes is a JavaScript "thing" and something that will most likely continue continue. Ember adds methods to Array.prototype and Function.prototype by default: http://emberjs.com/api

RE: Array.prototype.contains solutions

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic Denicola > Or you could attack the problem at the for-in level This half-sentence was a leftover from an earlier pass; please ignore it. ___ es-discuss mailing list es-discu

Re: Array.prototype.contains

no, my concern is about having different results between .contains() and .indexOf() in production code ... the NaN was the most obvious case/example on how that could go deadly wrong. if a.contains(v) i = a.indexOf(v); now enjoy inconsistency with what you were expecting ^_^ Just to clarify, I am

Re: Array.prototype.contains

On 7/24/14, Andrea Giammarchi wrote: > What is this about? Not an answer nor a solution to what I've said... > Just think that NaN is rarely an explicit value, rather something > potentially generated at runtime. Would > you .some(Number.isNAN.bind(Number)) all the Arrays? I don't think so, > at l

RE: Array.prototype.contains

y Windows Phone From: Garrett Smith Sent: ‎7/‎23/‎2014 22:31 To: Andrea Giammarchi Cc: Alex Vincent; es-discuss@mozilla.org Subject: Re: Array.prototype.contains On 7/23/14, Andrea Giammarchi wrote: > agreed, already imagining loops like > > ```js > while (arr.contains(value)) arr.remove

Re: Array.prototype.contains

Would Array.prototype.removeAll(element); be worth considering? In the same vein as querySelector/querySelectorAll? On Wed, Jul 23, 2014 at 4:05 PM, Alex Vincent wrote: > On Wed, Jul 23, 2014 at 2:00 PM, Michael Haufe > wrote: > >> Array.prototype.removeAt(index); >> Array.prototype.remove(ele

Re: Array.prototype.contains

On 7/23/14, Andrea Giammarchi wrote: > agreed, already imagining loops like > > ```js > while (arr.contains(value)) arr.remove(value); > ``` > > although that looks a bit nicer than > > ```js > var i; > while (-1 < (i = arr.indexOf(value))) arr.splice(i, 1); > ``` > > my main concern about `.conta

Re: Array.prototype.contains

agreed, already imagining loops like ```js while (arr.contains(value)) arr.remove(value); ``` although that looks a bit nicer than ```js var i; while (-1 < (i = arr.indexOf(value))) arr.splice(i, 1); ``` my main concern about `.contains()` is its potentially un-optimal implementation and error

Re: Array.prototype.contains

On Wed, Jul 23, 2014 at 2:00 PM, Michael Haufe wrote: > Array.prototype.removeAt(index); > Array.prototype.remove(element); > We already have an equivalent of removeAt: Array.prototype.splice(index, 1). My concern about remove still stands. -- "The first step in confirming there is a bug in

Re: Array.prototype.contains

Array.prototype.removeAt(index); Array.prototype.remove(element); On Wed, Jul 23, 2014 at 3:12 PM, Alex Vincent wrote: > On Wed, Jul 23, 2014 at 11:18 AM, wrote: > >> So too, for cases of removing an item, would Array.prototype.remove(v) >> show clear intent. >> > > I would actually raise a c

Re: Array.prototype.contains

On Wed, Jul 23, 2014 at 11:18 AM, wrote: > So too, for cases of removing an item, would Array.prototype.remove(v) > show clear intent. > I would actually raise a concern about that method. Suppose v shows up in the array more than once. Do you remove the first appearance, the last, or all of t

Re: Array.prototype.contains

On 7/23/14, Maël Nison wrote: > Isn't replacing DOMStringList a different issue than adding > Array.prototype.contains ? > > Using indexOf is possible, but a .contains() method would give a stronger > notice of intent when reading code. > So too, for cases of removing an item, would Array.prototy

RE: Array.prototype.contains

it through the post-ES6 spec process very quickly, including into implementations. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Will Ray Sent: Wednesday, July 23, 2014 12:42 To: Maël Nison Cc: Brendan Eich; es-discuss@mozilla.org Subject: Re: Array.prototype.contains

Re: Array.prototype.contains

Array.prototype.contains has been approved for the ES7 process: https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-04/apr-9.md#45-arrayprototypecontains Rick On Wed, Jul 23, 2014 at 12:41 PM, Will Ray wrote: > Additionally, .contains() can be used in a conditional statement directly,

Re: Array.prototype.contains

Additionally, .contains() can be used in a conditional statement directly, while .indexOf() requires the result of a comparison with -1 (or a bitwise inversion, which is not terribly intuitive). It's just more room for simple typos. Will Ray On Wed, Jul 23, 2014 at 5:29 AM, Maël Nison wrote: >

Re: Array.prototype.contains

Isn't replacing DOMStringList a different issue than adding Array.prototype.contains ? Using indexOf is possible, but a .contains() method would give a stronger notice of intent when reading code. On 7 March 2014 15:11, Boris Zbarsky wrote: > On 3/6/14 6:15 PM, Joshua Bell wrote: > >> FWIW, Bl

Re: Array.prototype.contains

On 3/6/14 6:15 PM, Joshua Bell wrote: FWIW, Blink uses DOMStringList only in IndexedDB and apparently in Location.ancestorOrigins Indeed. And Location.ancestorOrigins is fairly new and not broadly implemented, so I don't expect its behavior to be a strong compat constraint. So I guess that

Re: Array.prototype.contains

On 3/6/14 6:45 PM, C. Scott Ananian wrote: And don't forget the related `DOMTokenList`, which is in Element.classList and thus used by everyone always. How is it related? DOMTokenList is indeed an API for a list of strings (sort of; they're pretty restricted in terms of what strings they can

Re: Array.prototype.contains

...and same for indexOf and lastIndexOf? ;-) On 7 mar 2014, at 13:33, Domenic Denicola wrote: > If that's the argument, then Array.prototype.contains should accept another > Array, not an element to check. > >> On Mar 7, 2014, at 5:49, "medikoo" wrote: >> >> Domenic Denicola-2 wrote >>> Pers

Re: Array.prototype.contains

If that's the argument, then Array.prototype.contains should accept another Array, not an element to check. > On Mar 7, 2014, at 5:49, "medikoo" wrote: > > Domenic Denicola-2 wrote >> Personally I think the more useful model to follow than >> `String.prototype.contains` is `Set.prototype.has`.

RE: Array.prototype.contains

Domenic Denicola-2 wrote > Personally I think the more useful model to follow than > `String.prototype.contains` is `Set.prototype.has`. API wise, arrays have much more in common with strings than with sets. Thinking ES5, they're both array-likes, set isn't. They share `length` property, their v

Re: Array.prototype.contains

Le 7 mars 2014 à 00:45, C. Scott Ananian a écrit : > And don't forget the related `DOMTokenList`, which is in > Element.classList and thus used by everyone always. > Indeed, and there is also the (less known) `htmlFor` property of the element, which is precisely a `DOMSettableTokenList`. S

Re: Array.prototype.contains

And don't forget the related `DOMTokenList`, which is in Element.classList and thus used by everyone always. The `contains` and `item` methods are in `DOMTokenList`, so they probably shouldn't be removed from `DOMStringList`. But I don't think anyone was seriously proposing that, just that `DOMSt

Re: Array.prototype.contains

FWIW, Blink uses DOMStringList only in IndexedDB and apparently in Location.ancestorOrigins On Thu, Mar 6, 2014 at 1:59 PM, Boris Zbarsky wrote: > On 3/6/14 4:49 PM, Brendan Eich wrote: > >> What's with all the "no one implements" (including #3) stuff in specs? >> > > IDL Arrays in general are

Re: Array.prototype.contains

On 3/6/14 4:49 PM, Brendan Eich wrote: What's with all the "no one implements" (including #3) stuff in specs? IDL Arrays in general are not implemented by anyone that I know of (and possibly ever). They were a new concept added in WebIDL that hasn't really caught on with implementations. In

Re: Array.prototype.contains

Boris Zbarsky wrote: 1) document.styleSheetSets. 2) Microdata API. 3) Various places in indexeddb. 4) The DataTransfer API. 5) Some sort of offline resource list API that's not part of any standard I can find. #1 is not implemented by anyone but Gecko, and the spec is claiming it's a DOMStrin

RE: Array.prototype.contains

Thanks very much Boris. It sounds like there isn't much of a cross-browser or standardized story on where `DOMStringList`, with its `contains()` and `item()` methods (yeah, I meant `item`) shows up. I'd be curious where it shows up in Blink, IE, and WebKit codebases. If the intersection is smal

Re: Array.prototype.contains

On 3/6/14 3:58 PM, Domenic Denicola wrote: That would not allow us to kill DOMStringList. Can we get more background on DOMStringList? Sure. It's used in the following places in Gecko, as far as I can tell: 1) document.styleSheetSets. 2) Microdata API. 3) Various places in indexeddb. 4) The

RE: Array.prototype.contains

> That would not allow us to kill DOMStringList. Can we get more background on DOMStringList? It seems unlikely that you could get away with replacing a string-only type, which, from the specs I can find, seems to be immutable and have an additional index() method, with an actual mutable any-ty

Re: Array.prototype.contains

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

Re: Array.prototype.contains

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 conf

Re: Array.prototype.contains

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

Re: Array.prototype.contains

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

RE: Array.prototype.contains

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

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 lik

Re: Array.prototype.contains

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

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

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

Re: Array.prototype.contains

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 Str

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-

Re: Array.prototype.contains

On Fri, Nov 2, 2012 at 4:30 PM, Allen Wirfs-Brock wrote: > There is no verifiable formal contract. But there can be an informal > contract. In my experience, it is very important when using a dynamic > language to recognize and try to support such informal contracts. > Well, I sort of agree. B

Re: Array.prototype.contains

On 11/03/2012 11:06 PM, Mark S. Miller wrote: > On Sat, Nov 3, 2012 at 10:13 PM, Axel Rauschmayer > wrote: >> (I am still sad we did not fix indexOf, lastIndexOf, and switch when we >> arguably had the chance.) > > Can you elaborate? We don’t have the chance, any

Re: Array.prototype.contains

On Sun, Nov 4, 2012 at 3:58 AM, Claus Reinke wrote: > The set of values actually contained by the WeakMap at any moment is >> non-deterministic, depending on the scheduling of gc. But this >> non-determinism is non-observable. WeakMap.contains would make it >> observable. >> > > a) this concise el

Re: Array.prototype.contains

The set of values actually contained by the WeakMap at any moment is non-deterministic, depending on the scheduling of gc. But this non-determinism is non-observable. WeakMap.contains would make it observable. a) this concise elaboration should be part of the spec, to reduce guessing about th

Re: Array.prototype.contains

On Sat, Nov 3, 2012 at 10:13 PM, Axel Rauschmayer wrote: > (I am still sad we did not fix indexOf, lastIndexOf, and switch when we > arguably had the chance.) > > > Can you elaborate? We don’t have the chance, any more? Would anything > break (or did, in tests)? > I am not aware of anyone gather

Re: Array.prototype.contains

> (I am still sad we did not fix indexOf, lastIndexOf, and switch when we > arguably had the chance.) Can you elaborate? We don’t have the chance, any more? Would anything break (or did, in tests)? How about only letting those methods find NaN, while letting them consider +0 and -0 equal? Axel

Re: Array.prototype.contains

Mark S. Miller wrote: WeakMap.has is fine (and already speced) because the presence of the association depends on the key. However, if the key is garbage, a strong ref to the value does not preserve the association in the map. Right! Thanks. /be On Sat, Nov 3, 2012 at 6:05 PM, Brendan Eich

Re: Array.prototype.contains

WeakMap.has is fine (and already speced) because the presence of the association depends on the key. However, if the key is garbage, a strong ref to the value does not preserve the association in the map. On Sat, Nov 3, 2012 at 6:05 PM, Brendan Eich wrote: > Is this true? I can see how enumerat

Re: Array.prototype.contains

Is this true? I can see how enumeration and size would leak the GC schedule, but to test has or contains, you need a strong ref, which means the key or value cannot yet be garbage. If you have the capability, there's no non-determinism. What am I missing? /be Allen Wirfs-Brock wrote: On Nov

Re: Array.prototype.contains

On Nov 3, 2012, at 4:53 PM, Mark S. Miller wrote: > On Fri, Nov 2, 2012 at 5:26 PM, Allen Wirfs-Brock > wrote: > > Also any reason contains should be provided for WeakMap? I not seeing why it > shouldn't be there too. > > Yes! > > The set of values actually contained by the WeakMap at any m

Re: Array.prototype.contains

On Fri, Nov 2, 2012 at 5:26 PM, Allen Wirfs-Brock wrote: > > Also any reason contains should be provided for WeakMap? I not seeing why > it shouldn't be there too. > Yes! The set of values actually contained by the WeakMap at any moment is non-deterministic, depending on the scheduling of gc. Bu

Re: Array.prototype.contains

On Fri, Nov 2, 2012 at 9:55 PM, Axel Rauschmayer wrote: > +1 > > I have always found Java’s collection API fairly intuitive. It could serve > as a role model, at least partially. > - Map: containsKey, containsValue > I'd rather see Set.prototype.values() defined for Map.prototype > - Set: cont

Re: Array.prototype.contains

+1 I have always found Java’s collection API fairly intuitive. It could serve as a role model, at least partially. - Map: containsKey, containsValue - Set: contains Note that it has an isEmpty() method. I would also want to have its methods for combining collections such as removeAll() and reta

Re: Array.prototype.contains

On Nov 2, 2012, at 5:45 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >>> "has" for keys (and possibly values of a Set, to preserve the value mapped >>> to boolean future option that forEach also supports), "contains" for values >>> in arrays >> >> sounds ok, except we get the same issue

Re: Array.prototype.contains

Allen Wirfs-Brock wrote: "has" for keys (and possibly values of a Set, to preserve the value mapped to boolean future option that forEach also supports), "contains" for values in arrays sounds ok, except we get the same issue for contains that we have for indexOf. II guess the big thing with

Re: Array.prototype.contains

On Nov 2, 2012, at 4:54 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> ... >> Note that we (the JS/ES designers) already have a history of being being >> inconsistent in our use of names. Consider String indexOf and Array indexOf > > http://stackoverflow.com/questions/4962361/where-is-j

Re: Array.prototype.contains

Andrea Giammarchi wrote: I actually agree on this, but Set.has() is misleading then, imho. Shouldn't be specified that `has()` is key related and `contains()` is value related? The forEach signature has (value, key, collection), and for a Set is called with (value, value, theSet). We discusse

Re: Array.prototype.contains

Allen Wirfs-Brock wrote: On Nov 2, 2012, at 10:56 AM, Jason Orendorff wrote: On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola mailto:dome...@domenicdenicola.com>> wrote: > If we call it "has", should we also rename String.prototype.contains? I'd say no; the distinction between co

Re: Array.prototype.contains

I actually agree on this, but Set.has() is misleading then, imho. Shouldn't be specified that `has()` is key related and `contains()` is value related? Also a "magic" Object.has(obj, key) with smart obj recognition and Object.contains(obj, value) would be probably cool On Fri, Nov 2, 2012 at 2:30

Re: Array.prototype.contains

On Nov 2, 2012, at 10:56 AM, Jason Orendorff wrote: > On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola > wrote: > > If we call it "has", should we also rename String.prototype.contains? > > I'd say no; the distinction between collections "having" an element and > strings "containing" a subst

Re: Array.prototype.contains

David Herman wrote: [Math.round(-0.1)].has(0) // false! Could be a problem, but my position is that anyone using Math.round has to deal with -0. It is observably different from 0 via other Math functions, even if ===. /be ___ es-discuss maili

Re: Array.prototype.contains

Erik Arvidsson > > If we call it "has", should we also rename String.prototype.contains? > > > Most of the JS libraries use `has` method for checking property and key existence. I am wondering if there is Array.prototype.has how they would overload their `has` methods to work as expected with arr

Re: Array.prototype.contains

On Nov 2, 2012, at 11:55 AM, Mark S. Miller wrote: > The only consistency issue is: should array.has agree with sense and all > other collections, or should it agree with array.indexOf / lastIndexOf. FWIW, > I would prefer not to add any more conveniences that further entrench > unexpected ===

Re: Array.prototype.contains

Fortunately, strings cannot contain -0.0 or NaN, so neither string.contains nor string.has sets any relevant precedent. FWIW, neither does string.indexOf nor string.lastIndexOf. The only consistency issue is: should array.has agree with sense and all other collections, or should it agree with arra

Re: Array.prototype.contains

http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has On Fri, Nov 2, 2012 at 2:04 PM, Rick Waldron wrote: > > On Friday, November 2, 2012 at 1:56 PM, Jason Orendorff wrote: > > On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola > wrote: > >> If we call it "has", should we also renam

Re: Array.prototype.contains

On Friday, November 2, 2012 at 1:56 PM, Jason Orendorff wrote: > On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola > mailto:dome...@domenicdenicola.com)> wrote: > > > If we call it "has", should we also rename String.prototype.contains? > > > > I'd say no; the distinction between collections "

Re: Array.prototype.contains

On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > > If we call it "has", should we also rename String.prototype.contains? > > I'd say no; the distinction between collections "having" an element and > strings "containing" a substring seems very sensible. It's

Re: Array.prototype.contains

On Fri, Nov 2, 2012 at 9:14 AM, Rick Waldron wrote: > > On Fri, Nov 2, 2012 at 11:25 AM, Allen Wirfs-Brock > wrote: > >> There is also the compat issue with Mootools with String contains... >> >> If we decided we needed to rename String contains then it might also >> impact what we call a simil

RE: Array.prototype.contains

-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Erik Arvidsson Sent: Friday, November 2, 2012 13:21 > If we call it "has", should we also rename String.prototype.contains? I'd say no; the distinction between collections "having

Re: Array.prototype.contains

+1 ... but funny that for Strings I would naturally use "mychunk" in mystring rather than mystring.has("mychunk") I believe contains comes from XSL, isn't it? Was it W3C suggestion or what? On Fri, Nov 2, 2012 at 10:20 AM, Erik Arvidsson wrote: > On Fri, Nov 2, 2012 at 12:30 PM, Mark S. Mil

Re: Array.prototype.contains

On Fri, Nov 2, 2012 at 1:20 PM, Erik Arvidsson wrote: > On Fri, Nov 2, 2012 at 12:30 PM, Mark S. Miller > wrote: > > I also support calling it "has" as Rick suggests. Perhaps this also helps > > suggest that it is like the other "has"s, which use SameValue, and not > like > > indexOf. > > > > (I

Re: Array.prototype.contains

On Fri, Nov 2, 2012 at 12:30 PM, Mark S. Miller wrote: > I also support calling it "has" as Rick suggests. Perhaps this also helps > suggest that it is like the other "has"s, which use SameValue, and not like > indexOf. > > (I am still sad we did not fix indexOf, lastIndexOf, and switch when we >

Re: Array.prototype.contains

I was wondering the same ... if `contains()` is the new indexOf then why other collections are using `has()` ... I like has() more but it might be me lazy typer ... still it should be consistent. On Fri, Nov 2, 2012 at 9:14 AM, Rick Waldron wrote: > > > On Fri, Nov 2, 2012 at 11:25 AM, Allen Wi

Re: Array.prototype.contains

On Fri, Nov 2, 2012 at 8:19 AM, Erik Arvidsson wrote: > I'll put up a proposal once electricity is back. I'll use the same > comparison as done in maps. > With it being the same comparison as maps (which use SameValue), +1. Note that this makes contains/has inconsistent with indexOf (which uses =

Re: Array.prototype.contains

On Fri, Nov 2, 2012 at 11:25 AM, Allen Wirfs-Brock wrote: > There is also the compat issue with Mootools with String contains... > > If we decided we needed to rename String contains then it might also > impact what we call a similar Array method > Perhaps it should be "has" instead of "contain

Re: Array.prototype.contains

There is also the compat issue with Mootools with String contains... If we decided we needed to rename String contains then it might also impact what we call a similar Array method Allen On Nov 2, 2012, at 8:19 AM, Erik Arvidsson wrote: > I'll put up a proposal once electricity is back. I'll

Re: Array.prototype.contains

I'll put up a proposal once electricity is back. I'll use the same comparison as done in maps. On Nov 2, 2012 2:03 AM, "Allen Wirfs-Brock" wrote: > > On Nov 1, 2012, at 11:04 AM, Joshua Bell wrote: > > Bump. > > I don't think Array.prototype.contains ever materialized on the > "proposals" page, a

Re: Array.prototype.contains

On Nov 1, 2012, at 11:04 AM, Joshua Bell wrote: > Bump. > > I don't think Array.prototype.contains ever materialized on the "proposals" > page, and hasn't shown up in an ES6 draft. > > Officially out for ES6, stuck in the queue, or dropped on the floor? Probably dropped on the floor, unless s

Re: Array.prototype.contains

Bump. I don't think Array.prototype.contains ever materialized on the "proposals" page, and hasn't shown up in an ES6 draft. Officially out for ES6, stuck in the queue, or dropped on the floor? On Fri, Feb 24, 2012 at 4:40 PM, Rick Waldron wrote: > Allen, thank you for the clarification there >

Re: Array.prototype.contains

Allen, thank you for the clarification there Rick On Feb 24, 2012, at 7:19 PM, Allen Wirfs-Brock wrote: > > On Feb 24, 2012, at 11:09 AM, Rick Waldron wrote: > >> >> >> On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson >> wrote: >> DOM4 added a new interface called DOMStringList for the so

  1   2   >