+1!
It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.
We definitely need mutable prototype, but having it via __proto__ really
breaks the language.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__:
I like to disagree. I was quite familiar with the ES spec about a year
ago and this still confused me. Only because this is pre-existing
doesn't make the language very clear.
Tom
On Sun, Mar 17, 2013 at 8:11 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Sat, Mar 16, 2013 at 7:56 PM,
On Wed, Mar 20, 2013 at 5:51 AM, Mariusz Nowak
medikoo+mozilla@medikoo.com wrote:
+1!
It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.
This was recorded as the resolution of record in January 2013
Mariusz Nowak wrote:
+1!
It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.
We've been over this many times, e.g. at
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html
To recap,
1. __proto__ is out in the field, a de-facto standard on
Tom Schuster wrote:
I like to disagree. I was quite familiar with the ES spec about a year
ago and this still confused me. Only because this is pre-existing
doesn't make the language very clear.
I agree it's a bit awkward learning to read every Clause 15 method spec
in terms of the Clause 15
I didn't get a direct response to my question about mutating proto on objects
which don't inherit from Object.prototype, but I'm inferring from [1] that it
won't be possible. I find this unfortunate, but I realize this issue has seen
a lot of discussion in the past and there are reasons for
Le 20/03/2013 16:36, Nathan Wall a écrit :
I didn't get a direct response to my question about mutating proto on objects
which don't inherit from Object.prototype, but I'm inferring from [1] that it
won't be possible. I find this unfortunate, but I realize this issue has seen
a lot of
Le 20/03/2013 16:15, Brendan Eich a écrit :
To recap,
1. __proto__ is out in the field, a de-facto standard on mobile, and
not going away. Adding another API doesn't help, it hurts.
2. SES and other secure subsets want same-frame (global object,
realm) mashups of code that may use __proto__
I don't understand where is the problem ... any library that uses __proto__
can and should be updated with a shim waiting for next version of JS to
support it.
Object.setPrototypeOf = function (object, proto) {
object.__proto__ = proto;
return object;
};
That does not look bad at all to me,
Negation on at least some x86-ish systems also produces another kind of NaN,
because the trivial negation implementation is a sign-bit flip.
This strikes me as similar to the endianness concerns of typed arrays, except
probably far less harmful in practice. I don't see what can reasonably be
On Mar 20, 2013, at 12:34 PM, Kevin Reid wrote:
On Wed, Mar 20, 2013 at 12:10 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Mar 20, 2013, at 10:09 AM, Kevin Reid wrote:
Depending on what you mean by “ECMAScript code”, this may be false given
the Typed Arrays extension, which
On 3/20/2013 12:56 PM, Allen Wirfs-Brock wrote:
If you're specifically talking about reading/writing TypedArray
elements (really ArrayBuffers) you have to take into account the
possibility that you can have different types overlaying the same
buffer storage. Hence a NaN bit pattern might be
On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
That normalization on read is is my case 1 above — it is necessary _for that
implementation_. A conformant implementation could use a different strategy
which does not normalize on Float64 read, and this would be unobservable, so
the spec
never cared about IE much on mobile and I do not care about 100% or
__proto__ support ... there is 100% of Object.prototype pollution support
since ever and everybody knows that is a bad technique, specially done
through direct property rather than through a descriptor.
What is the point then ?
On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
That normalization on read is is my case 1 above — it is necessary _for
that implementation_. A conformant implementation could use a different
strategy which does
On Wed, Mar 20, 2013 at 2:24 PM, Kevin Reid kpr...@google.com wrote:
On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
That normalization on read is is my case 1 above — it is necessary _for
that implementation_. A
The proposal we accepted, written by Andreas at
http://wiki.ecmascript.org/doku.php?id=harmony:refutable_matching, seems
clear. Patterns are refutable without an extra ? annotation. Andreas is
using prefix-?, note well.
/be
Axel Rauschmayer wrote:
Are patterns in parameter declarations
On Mar 20, 2013, at 2:38 PM, Kenneth Russell wrote:
The typed array specification in its original form deliberately
avoided specifying normalization of NaNs upon writes to Float32Array
and Float64Array. Doing so has no practical value and only imposes a
performance hit, which is
18 matches
Mail list logo
