RE: Mutable Proto
+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.prototype }).
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
That's bad, and it's hard for me to believe we can't do it better.
François REMY-3 wrote:
I certainly agree, but it has been decided otherwhise by the TC39 members
and I doubt they’re willing to revert their decision.
De : Andrea Giammarchi
Envoyé : 18 mars 2013 17:08
À : Nathan Wall
Cc : es-discuss@mozilla.org
Objet : Re: Mutable Proto
I would like to see Object.setPrototypeOf(object, proto) too and a
disappeared __proto__ 'till now breaking too much.
It would be much easier to implement all shenanigans via
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather
than fix current non-standard __proto__ ...
+1
On Mon, Mar 18, 2013 at 9:04 AM, Nathan Wall nathan.w...@live.com wrote:
A previous thread [1] brought to my attention the fact that objects which
don't inherit from Object.prototype won't have mutable __proto__. This
was something I had missed and breaks some scripts I'm currently using
because I have objects which I don't want to inherit from Object.prototype
but for which I do want to have mutable proto.
Testing in Firefox Nightly I found this workaround:
var x = { }, y = { foo: 'bar' };
x.__proto__ = y;
console.log(1, x.foo);
// = 1 'bar'
x.__proto__ = null;
console.log(2, x.foo);
// = 2 undefined
x.__proto__ = y;
console.log(3, x.foo);
// = 3 undefined
var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set,
setPrototypeOf = Function.prototype.call.bind(_setPrototype);
setPrototypeOf(x, y);
console.log(4, x.foo);
// = 4 'bar'
Is this workaround a temporary bug in Firefox's current implementation? Or
will this be the spec'ed behavior for ES6? Can we use such a method to
mutate prototype on objects which don't inherit from Object.prototype?
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Mutable-Proto-tp35188550p35196276.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.is steps are very thing
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, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 16, 2013, at 4:42 PM, Tom Schuster wrote: I would argue that the disclaimer makes this more confusing. I am aware of the behavior that not passed parameters are undefined. But It sounded like we would never execute step 1. when the parameter count doesn't match. And thus leaving the result of the call not defined. I see...it certainly isn't intended for those preambles to be interpreted in that way. They really are just boiler plate for inducing the the italic parameter names. If there is an actual overload based upon the number of passed arguments we are much more explict. See for example, 15.4.1.1 and 15.4.1.2. Nobody had previously brought this particular point of confusion to may attention. It should like I shold change the standard boiler plate preamble to something slike: The *is* function takes parameters /value1/ and /value2/ and performs the following steps when called: I disagree that the language is at all confusing. The existing preamble is consistent and makes sense in the context of describing a public API that delegates to an abstract operation. If the reader needs any further information about the semantics of Object.is, the algorithmic steps for SameValue are thorough. Rick Allen On Sun, Mar 17, 2013 at 12:06 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 16, 2013, at 3:40 PM, David Bruant wrote: Le 16/03/2013 19:18, Tom Schuster a écrit : Hey! Looking at the the steps for Object.is the first sentence just says: When the is function is called with arguments value1 and value2 the following steps are taken: I don't remember other functions being defined like that. It should at least say something along the lines of When called with less than 2 parameters return false. I'd throw a TypeError. Calling Object.is with strictly more or less than 2 parameters is most likely an error, akin to === with which something different than strictly 2 operands resultsis a SyntaxError. ECMAScript has a well established convention of using undefined for any non-supplied argument values. It's preferable to consistently follow such conventions. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
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/master/es6/2013-01/jan-29.md#45-why-standardizing-on-proto-and-not-definegsetter-lookupgsetter,
specifically:
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html
Rick
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.prototype }).
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
That's bad, and it's hard for me to believe we can't do it better.
François REMY-3 wrote:
I certainly agree, but it has been decided otherwhise by the TC39 members
and I doubt they’re willing to revert their decision.
De : Andrea Giammarchi
Envoyé : 18 mars 2013 17:08
À : Nathan Wall
Cc : es-discuss@mozilla.org
Objet : Re: Mutable Proto
I would like to see Object.setPrototypeOf(object, proto) too and a
disappeared __proto__ 'till now breaking too much.
It would be much easier to implement all shenanigans via
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather
than fix current non-standard __proto__ ...
+1
On Mon, Mar 18, 2013 at 9:04 AM, Nathan Wall nathan.w...@live.com
wrote:
A previous thread [1] brought to my attention the fact that objects which
don't inherit from Object.prototype won't have mutable __proto__. This
was something I had missed and breaks some scripts I'm currently using
because I have objects which I don't want to inherit from
Object.prototype
but for which I do want to have mutable proto.
Testing in Firefox Nightly I found this workaround:
var x = { }, y = { foo: 'bar' };
x.__proto__ = y;
console.log(1, x.foo);
// = 1 'bar'
x.__proto__ = null;
console.log(2, x.foo);
// = 2 undefined
x.__proto__ = y;
console.log(3, x.foo);
// = 3 undefined
var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set,
setPrototypeOf = Function.prototype.call.bind(_setPrototype);
setPrototypeOf(x, y);
console.log(4, x.foo);
// = 4 'bar'
Is this workaround a temporary bug in Firefox's current implementation?
Or
will this be the spec'ed behavior for ES6? Can we use such a method to
mutate prototype on objects which don't inherit from Object.prototype?
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Mutable-Proto-tp35188550p35196276.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
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 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__ and code that must not, but
Object.setPrototypeOf is a per-frame capability that would have to be
removed, breaking the former class of code.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).
No, that depends on how extend works. If it uses Object.defineProperty
or equivalent, then nothing is broken and the setter on Object.prototype
for __proto__ is not run.
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
Only if you use assignment into an object that delegates to
Object.prototype, but see (1) above: this hazard already exists. Don't
do that; JSON doesn't, and Object.create(null) gives a way to create
dictionaries.
Yes, the problems you cite are real, but they are already part of the
de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a
mistake due to (2).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.is steps are very thing
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 intro's subtle language about missing arguments. Kind of a pain, really. But in the interest of a minimal spec, to avoid redundancy that can then mutate and diverge, making spec bugs, we generally try to hoist such common code, if you will. Do you think a specific change should be made for Object.is, or for all method specs in 15? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Mutable Proto
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 current decision.
I will see how I can make my code cope with reality.
Nathan
Brendan Eich wrote:
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 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__ and code that must not, but
Object.setPrototypeOf is a per-frame capability that would have to be
removed, breaking the former class of code.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).
No, that depends on how extend works. If it uses Object.defineProperty
or equivalent, then nothing is broken and the setter on Object.prototype
for __proto__ is not run.
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
Only if you use assignment into an object that delegates to
Object.prototype, but see (1) above: this hazard already exists. Don't
do that; JSON doesn't, and Object.create(null) gives a way to create
dictionaries.
Yes, the problems you cite are real, but they are already part of the
de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a
mistake due to (2).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
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 discussion in the past and there are reasons for the current decision.
I will see how I can make my code cope with reality.
Could you describe how you use __proto__ on objects not inheriting from
Object.prototype?
From what I know there are 2 main use cases:
1) object as map
changing the prototype enable changing different default values. I
guess any solution to that problem either looses the object syntax
(maybe unless using proxies) like using an ES6 Map or has non-trivial
runtime cost.
Or the code needs to be reorganized so that the object is always created
after the prototype (using Object.create for instance)
2) Subclassing
ES6 will have classes with inheritance. That's mostly syntax sugar on
top of what's already possible, but that works.
Do you have a use case that belongs in neither of these categories?
David
Nathan
Brendan Eich wrote:
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 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__ and code that must not, but
Object.setPrototypeOf is a per-frame capability that would have to be
removed, breaking the former class of code.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).
No, that depends on how extend works. If it uses Object.defineProperty
or equivalent, then nothing is broken and the setter on Object.prototype
for __proto__ is not run.
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
Only if you use assignment into an object that delegates to
Object.prototype, but see (1) above: this hazard already exists. Don't
do that; JSON doesn't, and Object.create(null) gives a way to create
dictionaries.
Yes, the problems you cite are real, but they are already part of the
de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a
mistake due to (2).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
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__ and code that must not, but Object.setPrototypeOf is a per-frame capability that would have to be removed, breaking the former class of code. (...) Yes, the problems you cite are real, but they are already part of the de-facto __proto__ standard (1). Agreed. From the spec/implementor point of view, __proto__ has to be added as de-facto standard because it is used. From the developer point of view, it is not because it's in the language that it's a good idea to use it. Quite the opposite, I'd like to reiterate that devs should make delete Object.prototype.__proto__ the second line of their code (first line is use strict;). Devs shouldn't make the mistake to think that __proto__ in the standard makes it a good or legitimate feature. __proto__ in ES6 is yet another ECMAScript Regret [1] David [1] https://github.com/DavidBruant/ECMAScript-regrets (I haven't found much time to write more, but issues are more interesting to read than just the part that's been written down) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable 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, educate developers out there that
__proto__ is harmful and forbidden 'cause saying we can't do much is
already used doesn't mean is OK to use it, same as polluting
Object.prototype, still possible, nobody does it (not in an old fashioned
way at least)
Best Regards
On Wed, Mar 20, 2013 at 9:27 AM, David Bruant bruan...@gmail.com wrote:
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__ and code that must not, but
Object.setPrototypeOf is a per-frame capability that would have to be
removed, breaking the former class of code.
(...)
Yes, the problems you cite are real, but they are already part of the
de-facto __proto__ standard (1).
Agreed.
From the spec/implementor point of view, __proto__ has to be added as
de-facto standard because it is used.
From the developer point of view, it is not because it's in the language
that it's a good idea to use it. Quite the opposite, I'd like to reiterate
that devs should make delete Object.prototype.__proto__ the second line
of their code (first line is use strict;).
Devs shouldn't make the mistake to think that __proto__ in the standard
makes it a good or legitimate feature.
__proto__ in ES6 is yet another ECMAScript Regret [1]
David
[1]
https://github.com/**DavidBruant/ECMAScript-regretshttps://github.com/DavidBruant/ECMAScript-regrets(I
haven't found much time to write more, but issues are more interesting
to read than just the part that's been written down)
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
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 done about it, without effectively mandating attempting NaN-substitution whenever the value to set might be NaN. But maybe someone smarter has ideas. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
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 allows direct access to the bit-patterns of float values (the Typed Arrays spec permits, but does not require, replacing a NaN value with any other NaN value on read or write). This is not how it is specified in the ES6 spec. See 15.13.5.1.3 steps 7.b 8.b and 15.13.5.1.4 steps 7.a 8.a. Normalization of NaN values is required on retrieval and permitted on stores form/to ArrayBuffers. I see. I was reading the Khronos version and hadn't realized it was included in ES6. The ES spec. requirement (which isn't new to ES6) still applies. If they expose observably different NaN values to any ECMAScript code they aren't conforming to the spec. Then it seems to me that the wording of the spec, while not self-contradictory, makes it unnecessarily unobvious how to correctly implement it. Consider these two cases (which I think are exhaustive): 1. The implementation uses exactly one bit pattern for JS values which are NaN. In this case, normalization is required on reads and is a no-op for writes. 2. The implementation represents JS values which are NaN using arbitrary NaN bit patterns (and SameValue considers them all equal). In this case, normalization is unnecessary for reads and necessary for writes (else, as my example code shows, the difference is observable which contradicts 8.1.5). Thus, normalization on write is either a no-op or necessary, so should be mandatory, and normalization on read is unobservable in either case, so need not be mandatory. 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 written as 2 Uint32 values and then retrieved as a Float64 value. In that case, there is no Float64 write to perform the normalization so it must be done on all reads. Such normalization is especially important if object pointers are represented using NaN-boxing. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
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 written as 2 Uint32 values and then retrieved as a Float64 value. In that case, there is no Float64 write to perform the normalization so it must be done on all reads. Such normalization is especially important if object pointers are represented using NaN-boxing. Allen Exactly, you can't control it on the write end. Writing two uint32's is precisely how you do NaN-tagging using typed arrays (since you can't write an uint64). The way to normalize is to coerce to a single canonical NaN on read, if anything. (an example of NaN-tagging using typed arrays: https://gist.github.com/Benvie/5021724) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
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 should not bother to specify it. However, lack of normalization on Float64 write _is_ potentially observable (if the implementation does not normalize all NaNs from all sources). Therefore, I argue, the spec should specify that normalization happens on write; and it happens that an implementation can omit that as an explicit step, with no observable difference, if and only if its representation of NaN in JS values (from all possible sources, not just typed arrays) is normalized. The buffer contents may have come form an external source or the buffer may be accessible for writes by an agent that is not part of the ES implementation. The only thing that the ES implementation has absolute control over are its own reads from a buffer and the values it propagates from those reads. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
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 ? Should I feel free to shoot in my foot and in all libraries foot because I can change even Object.prototype.__proto__ ? I don't think so and I don't understand what is anyone point here. TC39 decided to do not even talk about __proto__ now is the best thing ever to suggest and use because supported ... is not standard and loads of shenanigans, is an undesired property full of undesired behaviors ... and still you all are protecting it for which reason, exactly? Either you make it standard, or you get rid of it ASAP allowing developers that use it already to migrate, gracefully, through Object.setPrototypeOf ... and considering setPrototypeOf, hidePrototypeOf, and freezePrototypeOf method in ES7 ... how does that sound? 'cause otherwise we can just stop reading specs, if non standard stuff is sacre more than specs and standards or potential, better, solutions. Best Regards On Wed, Mar 20, 2013 at 1:33 PM, Rick Waldron waldron.r...@gmail.comwrote: 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 honest and I don't think is a good idea to use it at all. My point is that Object.setPrototypeOf does not need a property loads of shenanigans as __proto__ is so that no Object.prototype.__proto__ would ever exist anywhere. I don't even know why that existed in first place,to be honest ... so do not use it, pass through Object.setPrototypeOf, same as you would suggest pass through Object.defineProperty instead of using Object.prototype.__defineGetter__ __defineSetters__, both de facto standards some time ago. IE never implemented the __defineGetter__ __defineSetter__ but they did implement the ES5 Object meta APIs and _are_ implementing __proto__ for parity with browsers that currently support it—this is the big difference. This is in addition to the rationale recorded here https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#45-why-standardizing-on-__proto__-and-not-__definegsetter__-__lookupgsetter__ Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
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 not normalize on Float64 read, and this would be unobservable, so the spec should not bother to specify it. However, lack of normalization on Float64 write _is_ potentially observable (if the implementation does not normalize all NaNs from all sources). Therefore, I argue, the spec should specify that normalization happens on write; and it happens that an implementation can omit that as an explicit step, with no observable difference, if and only if its representation of NaN in JS values (from all possible sources, not just typed arrays) is normalized. The buffer contents may have come form an external source or the buffer may be accessible for writes by an agent that is not part of the ES implementation. The only thing that the ES implementation has absolute control over are its own reads from a buffer and the values it propagates from those reads. I don't think we're disagreeing about any facts or principles (everything in your paragraph above is true), but you're thinking about implementation strategies and I'm thinking about observable behavior. This is the important point: normalization on write _or observably-equivalent behavior_ is implicitly mandatory because otherwise 8.1.5 may fail to hold (standard ES code can use standard ES tools to distinguish NaNs, as demonstrated by my test results — the behavior I found does not contradict the spec, to my knowledge). Therefore, the spec should not claim that it is optional. _Incidentally_, I observe that normalization on read is not necessary except as an implementation strategy. It may well be that all implementations will find it expedient, but there is no need for the spec to require it, since (as 8.1.5 specifically acknowledges) an implementation may choose to let the NaN bits vary, as long as all operations on them (which includes SetValueInBuffer by my above argument) treat them identically. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
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 conformant implementation could use a different strategy which does not normalize on Float64 read, and this would be unobservable, so the spec should not bother to specify it. However, lack of normalization on Float64 write _is_ potentially observable (if the implementation does not normalize all NaNs from all sources). Therefore, I argue, the spec should specify that normalization happens on write; and it happens that an implementation can omit that as an explicit step, with no observable difference, if and only if its representation of NaN in JS values (from all possible sources, not just typed arrays) is normalized. The buffer contents may have come form an external source or the buffer may be accessible for writes by an agent that is not part of the ES implementation. The only thing that the ES implementation has absolute control over are its own reads from a buffer and the values it propagates from those reads. I don't think we're disagreeing about any facts or principles (everything in your paragraph above is true), but you're thinking about implementation strategies and I'm thinking about observable behavior. This is the important point: normalization on write _or observably-equivalent behavior_ is implicitly mandatory because otherwise 8.1.5 may fail to hold (standard ES code can use standard ES tools to distinguish NaNs, as demonstrated by my test results — the behavior I found does not contradict the spec, to my knowledge). Therefore, the spec should not claim that it is optional. 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 unacceptable for applications trying to reach the highest possible performance. I hope that the ES6 integration of typed arrays will not require normalization of NaNs on write, even if other specification changes need to be made to avoid requiring it. -Ken _Incidentally_, I observe that normalization on read is not necessary except as an implementation strategy. It may well be that all implementations will find it expedient, but there is no need for the spec to require it, since (as 8.1.5 specifically acknowledges) an implementation may choose to let the NaN bits vary, as long as all operations on them (which includes SetValueInBuffer by my above argument) treat them identically. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Patterns in parameter declarations: irrefutable?
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 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 happens if we call foo({})?
1. An exception is thrown
2. undefined is returned
I’m asking, because I’ve seen the pattern
function foo({ opt1 = 3 } = {}) { return opt1 }
If explicitly marking something as irrefutable is necessary, I’d prefer:
function foo({ opt1 = 3 }?) { return opt1 }
It’s a bit of a shame that destructuring and parameter declarations
diverge, but I guess it can’t be helped.
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de
home: rauschma.de http://rauschma.de
twitter: twitter.com/rauschma http://twitter.com/rauschma
blog: 2ality.com http://2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
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 unacceptable for applications trying to reach the highest possible performance. I hope that the ES6 integration of typed arrays will not require normalization of NaNs on write, even if other specification changes need to be made to avoid requiring it. Here is the exact language that is in the current ES6 draft for storing a Number into a buffer as a Float64 (rawValue is the value that gets stored into the buffer): Set rawValue to the 8 bytes that are the IEEE-868-2005 binary64 format encoding of value. If isBigEndian is true, the bytes are arranged in big endian order. Otherwise, the bytes are arranged in little endian order. If value is NaN, rawValue is may be set to any implementation choosen non-signaling NaN encoding. Allen -Ken _Incidentally_, I observe that normalization on read is not necessary except as an implementation strategy. It may well be that all implementations will find it expedient, but there is no need for the spec to require it, since (as 8.1.5 specifically acknowledges) an implementation may choose to let the NaN bits vary, as long as all operations on them (which includes SetValueInBuffer by my above argument) treat them identically. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
