yes, SES, the non real world out there, needs __proto__ ... shenanigans all
over the world because of '__proto__' ain't important.
Thanks to be clear on it
On Wed, Mar 20, 2013 at 10:18 PM, Brendan Eich wrote:
> Your writing is unclear and overlong, and full of unjustified airs of
> grievance
Your writing is unclear and overlong, and full of unjustified airs of
grievance -- please work on it.
To recap yet again (last time): __proto__ is a de-facto standard we
cannot defeat, whether anyone likes it or not. Adding
Object.setPrototypeOf does not help, because code won't migrate to it
http://wiki.ecmascript.org/doku.php?id=harmony:refutable_matching
- Would love to see examples for arrays. Especially if there are more element
patterns (lhs) than array elements (rhs).
- Possible future extensions: Make pattern after "..." optional, allow "..." in
the middle of an array. Examp
Thanks, didn’t know that applied to parameters, too. Then the following two
functions are equivalent(?)
function (arg0, arg1, arg2) {
// ...
}
function (...args) {
let [arg0', arg1', arg2'] = args;
// ...
}
With the following rules for translating argi ->
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 una
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 irrefu
On Wed, Mar 20, 2013 at 2:24 PM, Kevin Reid wrote:
> On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock
> 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 conformant implementati
On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock 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 conformant implementation could use a different
>> strategy which does not normalize on Fl
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 ? Sh
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 sp
On Wed, Mar 20, 2013 at 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.
>
Yes, that was my
On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I think zepto is using that to modify runtime NodeList results after
> querySelectorAll but in any case it was not me saying that __proto__ is
> used already. I use it only to shim getPrototypeOf to be hones
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 wr
David Bruant wrote:
> 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
>>
On Mar 20, 2013, at 12:34 PM, Kevin Reid wrote:
> On Wed, Mar 20, 2013 at 12:10 PM, Allen Wirfs-Brock
> 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 allows direct a
Are patterns in parameter declarations irrefutable? In other words, given:
function foo({ opt1 }) { return opt1 }
What happens if we call foo()?
1. An exception is thrown
2. undefined is returned
I’d expect (2). If opt1 had a default value, I’d expect that value to be
returned.
What
I think zepto is using that to modify runtime NodeList results after
querySelectorAll but in any case it was not me saying that __proto__ is
used already. I use it only to shim getPrototypeOf to be honest and I don't
think is a good idea to use it at all.
My point is that Object.setPrototypeOf doe
On Wed, Mar 20, 2013 at 12:10 PM, Allen Wirfs-Brock
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 allows direct access to the bit-patterns
> of float values (the Typed Arra
Le 20/03/2013 19:08, Jeff Walden a écrit :
I don't see what can reasonably be done about it, without effectively mandating
attempting NaN-substitution whenever the value to set might be NaN.
+1. I think Safari needs to be fixed.
Stuffing info in NaNs sounds superfluous. JS has objects, arrays,
Le 20/03/2013 19:04, Andrea Giammarchi a écrit :
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.
Which library? What are the inconsistencies between the current
__proto__ draft spec a
On Mar 20, 2013, at 11:08 AM, Jeff Walden wrote:
> 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
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 do
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, e
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 __prot
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 discuss
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 the
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
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 "mo
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
https://github.com/rwldrn/tc39-notes/blob/
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 wrote:
>
>
>
> On Sat, Mar 16, 2013 at 7:56 PM, Allen Wirfs-Brock
> wr
+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__: Error.p
31 matches
Mail list logo
