>
>
> 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
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
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
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
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
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
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
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
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
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
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.
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;
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.
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
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
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
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.
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
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
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]],
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
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
22 matches
Mail list logo
