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,
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
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
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 those ideas
Giammarchi andrea.giammar...@gmail.com; es-discuss
es-discuss@mozilla.org
Subject: Re: Having a non-enumerable Array.prototype.contains may not
beweb-compatible
So put ES7 features behind a flag until the water clears a bit. We'll get
there.
It kind of surprises me (a good surprise) that now
Old sites with old version of Mootools will have problems when trying
to use native Array.prototype.contains. Is that the only problem or is
there something else I'm missing?
On 10/7/14, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
FYI: from a MooTools core developer:
https
Orendorff jason.orendo...@gmail.com
Cc: Andrea Giammarchi andrea.giammar...@gmail.com; es-discuss
es-discuss@mozilla.org
Subject: Re: Having a non-enumerable Array.prototype.contains may not
beweb-compatible
So put ES7 features behind a flag until the water clears a bit. We'll get there.
It kind
`Array.prototype.contains` a getter, with a setter that does
[[DefineOwnProperty]].
This could work, and it requires no new kernel mechanisms. If we do
adopt this solution, the setter should be careful to play the same
games that SES plays to work around the override mistake
enumerableWhenAssigned(
Array.prototype,
'contains',
Array.prototype.contains
);
function enumerableWhenAssigned(obj, prop, value) {
Object.defineProperty(
obj,
prop,
{
configurable: true,
get: function () {
return value;
},
set: function (value
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
Le 1 oct. 2014 à 04:43, Mark S. Miller 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.
If we only fix the override mistake, still likely worth it. But if a new
with Mark that unless this solves a larger 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; es-discuss
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; es-discuss@mozilla.org
Subject: Re
On Wed, Oct 1, 2014 at 12:21 AM, Brendan Eich bren...@mozilla.org 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
that the addition of such an attribute
should not trigger much BC issues, but that needs to be examined more
closely.
If it's opt-in, e.g. we define Array.prototype.contains with
[[Overridable]] among its attributes, then at least MooTools works.
What could break? Code that did not expect 'contains
that the addition of such an attribute should
not trigger much BC issues, but that needs to be examined more closely.
If it's opt-in, e.g. we define Array.prototype.contains with
[[Overridable]] among its attributes, then at least MooTools works.
What could break? Code that did not expect 'contains' to exist
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
glance, I expect that the addition of such an attribute should
not trigger much BC issues, but that needs to be examined more closely.
If it's opt-in, e.g. we define Array.prototype.contains with [[Overridable]]
among its attributes, then at least MooTools works.
What could break? Code that did
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
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 9/30/14, 2:45 PM, Michał Wadas wrote:
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.
I didn't say we need to make it enumerable.
I said that given the current state of the web, a web browser cannot
ship a non-enumerable method named contains on
the current state of the web ... with all due respect for that library,
it's been years since I've heard anything about it.
It's also common on the old web to loop over Arrays via `for/in` to avoid
checks for sparse indexes through the entire length ... so making anything
enumerable in that
MooTools breaking because of additions/changes is not a new thing. It has
been broken in the past by things like Function#bind, String#contains,
Moz removing document.getBoxObjectFor.
Its activity has slowed overall though there is an effort to re-energize
core contributions. Their core has put
The problem is not people actively developing it, or creating new content with
it. The problem is _existing_ content that might break. All libraries have
periods where they are in vogue, and then fade out leaving detritus that hangs
around for years/decades on major sites.
--Oliver
On Sep
On Tue, Sep 30, 2014 at 3:45 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
the current state of the web ... with all due respect for that library,
it's been years since I've heard anything about it.
Seconded—arguably MooTools' decline in usership is because of conflicts
such as
On Tue, Sep 30, 2014 at 4:02 PM, Oliver Hunt oli...@apple.com wrote:
The problem is not people actively developing it, or creating new content
with it. The problem is _existing_ content that might break. All libraries
have periods where they are in vogue, and then fade out leaving detritus
Welp, nothing to do but add @@unMooToolsables.
From: Boris Zbarskymailto:bzbar...@mit.edu
Sent: 2014-09-30 19:21
To: es-discussmailto:es-discuss@mozilla.org
Subject: Having a non-enumerable Array.prototype.contains may not be
web-compatible
See https
On 9/30/14, 3:45 PM, Andrea Giammarchi wrote:
the current state of the web ... with all due respect for that
library, it's been years since I've heard anything about it.
They have ears, but cannot hear...
This is a reasonably commonly used library, as libraries go.
-Boris
On Tue, Sep 30, 2014 at 4:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/30/14, 3:45 PM, Andrea Giammarchi wrote:
the current state of the web ... with all due respect for that
library, it's been years since I've heard anything about it.
They have ears, but cannot hear...
This is a
Just a heads up, I've pinged MooTools core to inquire about fast-pathing a
patch release for Array#contains.
- JDD
On Tue, Sep 30, 2014 at 1:29 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Tue, Sep 30, 2014 at 4:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/30/14, 3:45 PM, Andrea
On 9/30/14, 4:29 PM, Rick Waldron wrote:
This may be helpful:
http://trends.builtwith.com/javascript/javascript-library
Rick, thank you!
This says 1.32% on top 10k sites, 3.05% on top 100k sites, 4.78% on top
million sites, and 6.39% overall.
There's definitely been a recent dip in those
On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas michalwa...@gmail.com wrote:
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.
Well -- true, that would break even more sites.
We're backing out Array#contains() for now. It's disappointing to me
personally -- that
There is no need to change the name.
MooTools has had these issues in the past (they've broke with ES5, ES6,
ES7 methods).
Array#contains is ES7 so there's time for their patch to release/propagate.
- JDD
On Tue, Sep 30, 2014 at 3:04 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On
I'm personally against unmaintained code and/or websites but here it's not
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these, apparently
historically known, problems.
Should ES7 be planned around all methods already
John-David Dalton wrote:
Just a heads up, I've pinged MooTools core to inquire about
fast-pathing a patch release for Array#contains.
Did you ask them to fix their code so it doesn't fail for any name, not
just for 'contains'? Thanks,
/be
___
Did you ask them to fix their code so it doesn't fail for any name, not
just for 'contains'? Thanks,
I didn't, but will follow up with that.
JDD
On Tue, Sep 30, 2014 at 3:50 PM, Brendan Eich bren...@mozilla.org wrote:
John-David Dalton wrote:
Just a heads up, I've pinged MooTools core to
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I'm personally against unmaintained code and/or websites but here it's not
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these,
On Tue, Sep 30, 2014 at 6:04 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas michalwa...@gmail.com
wrote:
Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.
Well -- true, that would break even more sites.
On Tue, Sep 30, 2014 at 7:24 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I'm personally against unmaintained code and/or websites but here it's
not
ES7 breaking the web, it's a library already
So put ES7 features behind a flag until the water clears a bit. We'll get
there.
It kind of surprises me (a good surprise) that now, because of JSFiddle,
there's super interest in MooTools. When in the past, when MooTools was
arguably more popular, it didn't stop the language and browsers from
Array.prototype.contains, that
would be ideal.
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
John-David Dalton
Sent: Wednesday, October 1, 2014 00:55
To: Jason Orendorff
Cc: es-discuss
Subject: Re: Having a non-enumerable Array.prototype.contains may not be
web-compatible
So put ES7
of e.g. making `Array.prototype.contains` a
getter, with a setter that does [[DefineOwnProperty]].
3. General hacks. I joked about @@unMooToolsables, but seriously, we could do
something similar to @@unscopables of using MOP hooks to fix this problem. One
idea that seems reasonable
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
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:
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]],
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
indexes.
2. Specific hacks. I am thinking of e.g. making `Array.prototype.contains`
a getter, with a setter that does [[DefineOwnProperty]].
This could work, and it requires no new kernel mechanisms. If we do adopt
this solution, the setter should be careful to play the same games that SES
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 ajvinc...@gmail.com wrote:
On Wed, Jul 23, 2014 at 2:00 PM, Michael Haufe t...@thenewobjective.com
wrote:
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 andrea.giammar...@gmail.com wrote:
agreed, already imagining loops like
```js
while (arr.contains(value)) arr.remove(value
On 7/24/14, Andrea Giammarchi andrea.giammar...@gmail.com 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?
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
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 bzbar...@mit.edu wrote:
On 3/6/14 6:15 PM, Joshua Bell
...@gmail.com 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.
On 7 March 2014 15:11, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/6/14 6
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 wray...@gmail.com wrote:
Additionally, .contains() can be used in a conditional
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
On 7/23/14, Maël Nison nison.m...@gmail.com 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
On Wed, Jul 23, 2014 at 11:18 AM, es-discuss-requ...@mozilla.org 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
Array.prototype.removeAt(index);
Array.prototype.remove(element);
On Wed, Jul 23, 2014 at 3:12 PM, Alex Vincent ajvinc...@gmail.com wrote:
On Wed, Jul 23, 2014 at 11:18 AM, es-discuss-requ...@mozilla.org wrote:
So too, for cases of removing an item, would Array.prototype.remove(v)
show
On Wed, Jul 23, 2014 at 2:00 PM, Michael Haufe t...@thenewobjective.com
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
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
On 7/23/14, Andrea Giammarchi andrea.giammar...@gmail.com 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
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
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 medikoo+mozilla@medikoo.com wrote:
Domenic Denicola-2 wrote
Personally I think the more useful model to follow than
`String.prototype.contains
...and same for indexOf and lastIndexOf? ;-)
On 7 mar 2014, at 13:33, Domenic Denicola dome...@domenicdenicola.com 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 medikoo+mozilla
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
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 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
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)
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
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
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
FWIW, Blink uses DOMStringList only in IndexedDB and apparently in
Location.ancestorOrigins
On Thu, Mar 6, 2014 at 1:59 PM, Boris Zbarsky bzbar...@mit.edu 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
Le 7 mars 2014 à 00:45, C. Scott Ananian ecmascr...@cscott.net 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 output
element, which is precisely a
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
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
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
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
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
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
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
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
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
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/
Hi,
In the latest draft, I see String.prototype.contains, but no
Array.prototype.contains
I see something about a no-brainer here
https://mail.mozilla.org/pipermail/es-discuss/2011-December/019108.html
I haven't found a bug on bugs.ecmascript or a mention in the meeting notes
On Fri, Nov 2, 2012 at 4:30 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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,
On 11/03/2012 11:06 PM, Mark S. Miller wrote:
On Sat, Nov 3, 2012 at 10:13 PM, Axel Rauschmayer a...@rauschma.de
mailto:a...@rauschma.de 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
On Sat, Nov 3, 2012 at 10:13 PM, Axel Rauschmayer a...@rauschma.de 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
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
On Sun, Nov 4, 2012 at 3:58 AM, Claus Reinke claus.rei...@talk21.comwrote:
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)
On Fri, Nov 2, 2012 at 9:55 PM, Axel Rauschmayer a...@rauschma.de 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
-
On Fri, Nov 2, 2012 at 5:26 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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
On Nov 3, 2012, at 4:53 PM, Mark S. Miller wrote:
On Fri, Nov 2, 2012 at 5:26 PM, Allen Wirfs-Brock al...@wirfs-brock.com
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
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
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 bren...@mozilla.org wrote:
Is this true? I
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
(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
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 somebody
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 al...@wirfs-brock.com wrote:
On Nov 1, 2012, at 11:04 AM, Joshua Bell wrote:
Bump.
I don't think Array.prototype.contains ever materialized
use the same comparison
as done in maps.
On Nov 2, 2012 2:03 AM, Allen Wirfs-Brock al...@wirfs-brock.com 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, and hasn't shown up in an ES6 draft
:
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 somebody can
1 - 100 of 143 matches
Mail list logo
