Re: [[Set]] and inherited readonly data properties
On 01 Apr 2014, at 4:47 , Mark S. Miller erig...@google.com wrote: Unless the committee revisits the override mistake, which seems unlikely, the only way to cope that I know of is to use tamperProof(obj) where you would have used freeze(obj). What library does tamperProof() come from? I can’t seem to find it in Caja. Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
On Tue, Apr 1, 2014 at 3:09 AM, Axel Rauschmayer a...@rauschma.de wrote: On 01 Apr 2014, at 4:47 , Mark S. Miller erig...@google.com wrote: Unless the committee revisits the override mistake, which seems unlikely, the only way to cope that I know of is to use tamperProof(obj) where you would have used freeze(obj). What library does tamperProof() come from? I can’t seem to find it in Caja. Once Caja (or just SES) is loaded, it is at cajaVM.tamperProof. It's defined at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#338 and made available on the cajaVM object at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#1351. See also https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#241 and https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#468 to understand some of the intricacies of getting the initialization order of this right for SES purposes. Often, tamperProof is used indirectly by Caja or SES code via cajaVM.def(obj) https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#1099 which applies tamperProof to obj, and to all objects reachable from obj via transitive reflective property and prototype traversal. Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
On 28 March 2014 23:00, Andrea Giammarchi andrea.giammar...@gmail.com wrote: For the sake of examples, I honestly find current V8 hack, tested in node.js inconsistent, kinda pointless, and quite disturbing, with or without strict code. I don't know what your notion of current is, but this bug has been fixed long ago. And being pointless is the nature of bugs. Why JavaScript engines need so much fragmentation with these kind of unspeced behavior ... this, as a developer, I've never got it. Just to annoy developers, of course. It's got nothing to do with the byzantine complexity of the language. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: [[Set]] and inherited readonly data properties
It's in the latest node v8 and i thought it was a hack introduced on purpose as mentioned before, apparently it's not, but still around. Sent from my Windows Phone From: Andreas Rossberg Sent: 3/31/2014 5:33 To: Andrea Giammarchi Cc: Brendan Eich; es-discuss Subject: Re: [[Set]] and inherited readonly data properties On 28 March 2014 23:00, Andrea Giammarchi andrea.giammar...@gmail.com wrote: For the sake of examples, I honestly find current V8 hack, tested in node.js inconsistent, kinda pointless, and quite disturbing, with or without strict code. I don't know what your notion of current is, but this bug has been fixed long ago. And being pointless is the nature of bugs. Why JavaScript engines need so much fragmentation with these kind of unspeced behavior ... this, as a developer, I've never got it. Just to annoy developers, of course. It's got nothing to do with the byzantine complexity of the language. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
Isn't such a behavior of Object.freeze potentially future-hostile? One of
the reasons why with went away was that adding new methods to standard
prototypes could break the code (what happened with
Array.prototype.values). But if Object.freeze is used to prevent others
from messing with builtins, as a way of defensive programming, the effect
could be the same. Imagine the code:
Object.freeze(Object.prototype);
// ...
var a = {};
a.field = 2;
If now some future ES version adds Object.prototype.field, this code starts
to break.
It seems that in its current definition freezing builtins should be
discouraged as future-hostile. Am I getting something wrong?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
Yes. This cure is worse than the disease. Object.freeze is important for
defensiveness for at least the reasons you state. The problem isn't just
new assignments like a.field = It is also old assignments like
function Point() {}
Point.prototype.toString = function() {}; // fails
Unless the committee revisits the override mistake, which seems unlikely,
the only way to cope that I know of is to use tamperProof(obj) where you
would have used freeze(obj).
Not fixing the override mistake was our biggest mistake in ES5. My
apologies for not raising the alarm until late, and not making the case
forcefully enough before it was too late. This is my single biggest regret
of all the time I've spent on TC39.
On Mon, Mar 31, 2014 at 2:37 PM, Michał Gołębiowski m.go...@gmail.comwrote:
Isn't such a behavior of Object.freeze potentially future-hostile? One of
the reasons why with went away was that adding new methods to standard
prototypes could break the code (what happened with
Array.prototype.values). But if Object.freeze is used to prevent others
from messing with builtins, as a way of defensive programming, the effect
could be the same. Imagine the code:
Object.freeze(Object.prototype);
// ...
var a = {};
a.field = 2;
If now some future ES version adds Object.prototype.field, this code
starts to break.
It seems that in its current definition freezing builtins should be
discouraged as future-hostile. Am I getting something wrong?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
my 2 cents, I think `Object.freeze()` is OK if used with objects that
should be frozen, most likely instances, not prototypes.
What's future and environmentally hostile is actually freezing the
`Object.prototype` not because of `freeze()`, rather because the same way
we should not extend to not break other libraries code, we should not feel
the owner of the `Object.prototype` freezing it.
I find both cases very obtrusive.
Best Regards
On Mon, Mar 31, 2014 at 2:47 PM, Mark S. Miller erig...@google.com wrote:
Yes. This cure is worse than the disease. Object.freeze is important for
defensiveness for at least the reasons you state. The problem isn't just
new assignments like a.field = It is also old assignments like
function Point() {}
Point.prototype.toString = function() {}; // fails
Unless the committee revisits the override mistake, which seems unlikely,
the only way to cope that I know of is to use tamperProof(obj) where you
would have used freeze(obj).
Not fixing the override mistake was our biggest mistake in ES5. My
apologies for not raising the alarm until late, and not making the case
forcefully enough before it was too late. This is my single biggest regret
of all the time I've spent on TC39.
On Mon, Mar 31, 2014 at 2:37 PM, Michał Gołębiowski m.go...@gmail.comwrote:
Isn't such a behavior of Object.freeze potentially future-hostile? One of
the reasons why with went away was that adding new methods to standard
prototypes could break the code (what happened with
Array.prototype.values). But if Object.freeze is used to prevent others
from messing with builtins, as a way of defensive programming, the effect
could be the same. Imagine the code:
Object.freeze(Object.prototype);
// ...
var a = {};
a.field = 2;
If now some future ES version adds Object.prototype.field, this code
starts to break.
It seems that in its current definition freezing builtins should be
discouraged as future-hostile. Am I getting something wrong?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
Mark I agree that writable:false, once inheritance is in the middle, is the
worst thing ever shipped in ES5 but once again this `tamperProof(obj)` you
keep mentioning won't work with IE9 Mobile (low share), webOS
(disappearing), and Android 2.3.X and lower (30% of Android web share) so
it's a not so good solution.
What is good is that as I've made `protoypal.Class` [1] function compatible
with `Object.freeze(Object.prototype)` so that your `Point` example would
be:
```javascript
Object.freeze(Object.prototype);
var Class = require('prototypal').Class;
var Point2D = Class({
constructor: function (x, y) {
this.x = x || 0;
this.y = y || 0;
},
toString: function () {
return '[object Point2D]';
}
});
'' + new Point2D; // [object Point2D]
```
anyone else could learn how to use `Object.defineProperty` which does not
suffer from frozen prototypes.
Long story short, `writable:false` is annoying, but not that difficult to
avoid for classes like architectures.
Cheers
[1] http://github.com/WebReflection/prototypal
On Mon, Mar 31, 2014 at 5:08 PM, Mark Miller erig...@gmail.com wrote:
For a non-prototypical object, obj, tamperProof(obj) is the same thing as
freeze(obj).
On Mon, Mar 31, 2014 at 3:56 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
my 2 cents, I think `Object.freeze()` is OK if used with objects that
should be frozen, most likely instances, not prototypes.
What's future and environmentally hostile is actually freezing the
`Object.prototype` not because of `freeze()`, rather because the same way
we should not extend to not break other libraries code, we should not feel
the owner of the `Object.prototype` freezing it.
I find both cases very obtrusive.
Best Regards
On Mon, Mar 31, 2014 at 2:47 PM, Mark S. Miller erig...@google.comwrote:
Yes. This cure is worse than the disease. Object.freeze is important for
defensiveness for at least the reasons you state. The problem isn't just
new assignments like a.field = It is also old assignments like
function Point() {}
Point.prototype.toString = function() {}; // fails
Unless the committee revisits the override mistake, which seems
unlikely, the only way to cope that I know of is to use tamperProof(obj)
where you would have used freeze(obj).
Not fixing the override mistake was our biggest mistake in ES5. My
apologies for not raising the alarm until late, and not making the case
forcefully enough before it was too late. This is my single biggest regret
of all the time I've spent on TC39.
On Mon, Mar 31, 2014 at 2:37 PM, Michał Gołębiowski
m.go...@gmail.comwrote:
Isn't such a behavior of Object.freeze potentially future-hostile? One
of the reasons why with went away was that adding new methods to standard
prototypes could break the code (what happened with
Array.prototype.values). But if Object.freeze is used to prevent others
from messing with builtins, as a way of defensive programming, the effect
could be the same. Imagine the code:
Object.freeze(Object.prototype);
// ...
var a = {};
a.field = 2;
If now some future ES version adds Object.prototype.field, this code
starts to break.
It seems that in its current definition freezing builtins should be
discouraged as future-hostile. Am I getting something wrong?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
For the sake of examples, I honestly find current V8 hack, tested in
node.js inconsistent, kinda pointless, and quite disturbing, with or
without strict code.
```javascript
function Class(value) {
this.value = value;
}
Object.defineProperties(Class.prototype, {
value: {value: null},
method: {value: Class}
});
var a = new Class(123);
a.value; // 123 ... why?
var b = Object.create(Class.prototype);
Class.call(b, 123);
b.method(123);
b.value; // null ... I mean ... **null**
```
Even worst when it comes to default values ...
```javascript
function A(value) {
this.value = value;
}
Object.defineProperty(
A.prototype,
'value',
{value: 0}
);
function B(value) {
if (value) {
// best of all .. it won't assign
// and it won't throw neither
// congrats?
this.value = value;
}
}
Object.defineProperty(
B.prototype,
'value',
{value: 0}
);
var a = new A(123);
a.value; // 123
a.value = 456;
a.value; // 456
var b = new B;
b.value; // 0
b.value = 456;
b.value; // 0
var b = new B(123);
b.value; // 0
b.value = 456;
b.value; // 0
```
Why JavaScript engines need so much fragmentation with these kind of
unspeced behavior ... this, as a developer, I've never got it.
Best Regards
On Thu, Mar 27, 2014 at 10:28 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I know it won't get updated any time soon but unfortunately, and specially
in some emerging market, [these kind of phones](
http://www.amazon.com/LG-Navigation-OPTIMUS-ME-BLK/dp/B005HEEBQI/ref=sr_1_62?s=electronicsie=UTF8qid=1395940823sr=1-62keywords=android+phone)
are still quite common ... you guys should speed up spreading FirefoxOS on
$25 deals !!!
Anyway, I was just saying Android 2.x is like the IE6 of these days, IMO
... and I am not sure it will go away any time soon.
Best Regards
On Wed, Mar 26, 2014 at 11:36 PM, Brendan Eich bren...@mozilla.orgwrote:
Andrea Giammarchi wrote:
on Android 2.3.6 (or lower) you can [try this page](http://www.3site.eu/
jstests/configurable.html) which will show an alert like
```
Sorry for the initial false alarm, at least I am sure few didn't know
about the getters and setters bug in actually quite recent Android 2
browsers.
Android 2.3 (Gingerbread) may be quite recent on a lower-end phone, but
it is incredibly out of date and not being maintained. Especially its old
WebKit fork. V8 was backported, but that was in 2010 -- pretty sure it is
not patched up to anywhere near current level.
http://en.wikipedia.org/wiki/Android_version_history#
Android_2.2.E2.80.932.2.3_Froyo_.28API_level_8.29
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
actually, if the value is passed, the `B` constructor will throw, but not
in `A`
Properties that has been directly assigned have no reason to be specified
as default in the prototype, if the constructor needs to directly assign
them ... right?
```javascript
function A(value) {
this.value = value || 0;
}
```
That's it, there is no reason to introduce an inconsistent behavior that
behaves in a completely unexpected way with properties maybe meant to be
inherited as non writable, as the specification, rightly or wrongly, say.
Will this ever be fixed? I start a post of 4 parts about descriptors, and
the more I write and test, the less I can explain people that ES5.1 is
actually a good standard ... there are so many little different things ...
but above one, I really don't get who even thought about it and why.
Apologies for the rant, I stop here, but I really hope this mess will be
cleaned up pretty soon.
Best Regards
On Fri, Mar 28, 2014 at 3:00 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
For the sake of examples, I honestly find current V8 hack, tested in
node.js inconsistent, kinda pointless, and quite disturbing, with or
without strict code.
```javascript
function Class(value) {
this.value = value;
}
Object.defineProperties(Class.prototype, {
value: {value: null},
method: {value: Class}
});
var a = new Class(123);
a.value; // 123 ... why?
var b = Object.create(Class.prototype);
Class.call(b, 123);
b.method(123);
b.value; // null ... I mean ... **null**
```
Even worst when it comes to default values ...
```javascript
function A(value) {
this.value = value;
}
Object.defineProperty(
A.prototype,
'value',
{value: 0}
);
function B(value) {
if (value) {
// best of all .. it won't assign
// and it won't throw neither
// congrats?
this.value = value;
}
}
Object.defineProperty(
B.prototype,
'value',
{value: 0}
);
var a = new A(123);
a.value; // 123
a.value = 456;
a.value; // 456
var b = new B;
b.value; // 0
b.value = 456;
b.value; // 0
var b = new B(123);
b.value; // 0
b.value = 456;
b.value; // 0
```
Why JavaScript engines need so much fragmentation with these kind of
unspeced behavior ... this, as a developer, I've never got it.
Best Regards
On Thu, Mar 27, 2014 at 10:28 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I know it won't get updated any time soon but unfortunately, and
specially in some emerging market, [these kind of phones](
http://www.amazon.com/LG-Navigation-OPTIMUS-ME-BLK/dp/B005HEEBQI/ref=sr_1_62?s=electronicsie=UTF8qid=1395940823sr=1-62keywords=android+phone)
are still quite common ... you guys should speed up spreading FirefoxOS on
$25 deals !!!
Anyway, I was just saying Android 2.x is like the IE6 of these days, IMO
... and I am not sure it will go away any time soon.
Best Regards
On Wed, Mar 26, 2014 at 11:36 PM, Brendan Eich bren...@mozilla.orgwrote:
Andrea Giammarchi wrote:
on Android 2.3.6 (or lower) you can [try this page](
http://www.3site.eu/jstests/configurable.html) which will show an
alert like
```
Sorry for the initial false alarm, at least I am sure few didn't know
about the getters and setters bug in actually quite recent Android 2
browsers.
Android 2.3 (Gingerbread) may be quite recent on a lower-end phone, but
it is incredibly out of date and not being maintained. Especially its old
WebKit fork. V8 was backported, but that was in 2010 -- pretty sure it is
not patched up to anywhere near current level.
http://en.wikipedia.org/wiki/Android_version_history#
Android_2.2.E2.80.932.2.3_Froyo_.28API_level_8.29
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
Andrea Giammarchi wrote: on Android 2.3.6 (or lower) you can [try this page](http://www.3site.eu/jstests/configurable.html) which will show an alert like ``` Sorry for the initial false alarm, at least I am sure few didn't know about the getters and setters bug in actually quite recent Android 2 browsers. Android 2.3 (Gingerbread) may be quite recent on a lower-end phone, but it is incredibly out of date and not being maintained. Especially its old WebKit fork. V8 was backported, but that was in 2010 -- pretty sure it is not patched up to anywhere near current level. http://en.wikipedia.org/wiki/Android_version_history#Android_2.2.E2.80.932.2.3_Froyo_.28API_level_8.29 /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
I know it won't get updated any time soon but unfortunately, and specially in some emerging market, [these kind of phones]( http://www.amazon.com/LG-Navigation-OPTIMUS-ME-BLK/dp/B005HEEBQI/ref=sr_1_62?s=electronicsie=UTF8qid=1395940823sr=1-62keywords=android+phone) are still quite common ... you guys should speed up spreading FirefoxOS on $25 deals !!! Anyway, I was just saying Android 2.x is like the IE6 of these days, IMO ... and I am not sure it will go away any time soon. Best Regards On Wed, Mar 26, 2014 at 11:36 PM, Brendan Eich bren...@mozilla.org wrote: Andrea Giammarchi wrote: on Android 2.3.6 (or lower) you can [try this page](http://www.3site.eu/ jstests/configurable.html) which will show an alert like ``` Sorry for the initial false alarm, at least I am sure few didn't know about the getters and setters bug in actually quite recent Android 2 browsers. Android 2.3 (Gingerbread) may be quite recent on a lower-end phone, but it is incredibly out of date and not being maintained. Especially its old WebKit fork. V8 was backported, but that was in 2010 -- pretty sure it is not patched up to anywhere near current level. http://en.wikipedia.org/wiki/Android_version_history# Android_2.2.E2.80.932.2.3_Froyo_.28API_level_8.29 /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
[[Set]] and inherited readonly data properties
use strict;
function Pony() {}
Object.freeze(Object.prototype);
Pony.prototype.toString = function () { return Pony; };
The last line here throws a TypeError in ES5 and ES6.* Can we change
it? To me, it stands to reason that you should be able to freeze
Object.prototype and not break your other code, as long as that code
doesn't actually try to modify Object.prototype.
This bit some Mozilla hackers in http://bugzil.la/980752.
Compatibility: Changing from throwing to not-throwing is usually ok.
In addition, I don't think Chrome implements this TypeError. So
presumably the web can't be depending on the exception.
Patch: Step 5.a of [[Set]] could be changed like from:
a. If ownDesc.[[Writable]] is false, return false.
to:
a. If ownDesc.[[Writable]] is false and O and Receiver are the
same object, return false.
-j
*Why I think it throws:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ordinary-object-internal-methods-and-internal-slots-set-p-v-receiver
Pony.prototype.[[Set]] reaches step 4.c. and tail-calls
Object.prototype.[[Set]], which reaches step 5.a. and returns false.
The TypeError is thrown from step 6.d. of PutValue:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-putvalue
which is called from step 1.f. from AssignmentExpression Evaluation:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-runtime-semantics-
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
Le 26/03/2014 19:24, Jason Orendorff a écrit :
use strict;
function Pony() {}
Object.freeze(Object.prototype);
Pony.prototype.toString = function () { return Pony; };
The last line here throws a TypeError in ES5 and ES6.* Can we change
it? To me, it stands to reason that you should be able to freeze
Object.prototype and not break your other code, as long as that code
doesn't actually try to modify Object.prototype.
It looks like the override mistake.
http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake
Mark Miller agrees with you. I agree with you.
The consensus is apparently that it is the desired behavior.
Threads on the topic:
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019562.html
https://mail.mozilla.org/pipermail/es-discuss/2013-March/029414.html
(there might be meeting notes on this topic too)
This bit some Mozilla hackers in http://bugzil.la/980752.
Compatibility: Changing from throwing to not-throwing is usually ok.
In addition, I don't think Chrome implements this TypeError.
I can observe it does in Chrome 33. (the REPL doesn't consider the use
strict; wrap in an IIFE to see the error being thrown)
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
On Mar 26, 2014, at 11:24 AM, Jason Orendorff wrote:
use strict;
function Pony() {}
Object.freeze(Object.prototype);
Pony.prototype.toString = function () { return Pony; };
The last line here throws a TypeError in ES5 and ES6.* Can we change
it? To me, it stands to reason that you should be able to freeze
Object.prototype and not break your other code, as long as that code
doesn't actually try to modify Object.prototype.
This bit some Mozilla hackers in http://bugzil.la/980752.
Compatibility: Changing from throwing to not-throwing is usually ok.
In addition, I don't think Chrome implements this TypeError. So
presumably the web can't be depending on the exception.
This change would not just eliminating a throw in strict mode. It is also
change sloppy mode behavior where such assignments have been silently ignored
since ES1. It would be a fundamental change to the meaning of the [[Writable]]
property attribute.
see http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake
(and links from that page)
also see the recent discussion at
https://github.com/getify/You-Dont-Know-JS/issues/91#issuecomment-38702332
So far we have not been able to reach a consensus on changing this. I don't
know whether report actually adds any new information or whether it will help
develop a consensus.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
This mistake is my single biggest regret from the ES5 days. We had a chance
to get this right when it would have been rather painless and we blew it.
Although it can no longer be fixed without a lot of pain, I still think the
pain of not fixing it will be greater. However, I'm sick of arguing about
this one and have become resigned to using tamperProof
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#338
rather than freeze. Using tamperProof rather than freeze, your example will
work.
If enough others become convinced that this still can and should be fixed,
we should still fix this. However, someone else would need to volunteer to
champion it within TC39. Any volunteers?
On Wed, Mar 26, 2014 at 11:48 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Mar 26, 2014, at 11:24 AM, Jason Orendorff wrote:
use strict;
function Pony() {}
Object.freeze(Object.prototype);
Pony.prototype.toString = function () { return Pony; };
The last line here throws a TypeError in ES5 and ES6.* Can we change
it? To me, it stands to reason that you should be able to freeze
Object.prototype and not break your other code, as long as that code
doesn't actually try to modify Object.prototype.
This bit some Mozilla hackers in http://bugzil.la/980752.
Compatibility: Changing from throwing to not-throwing is usually ok.
In addition, I don't think Chrome implements this TypeError. So
presumably the web can't be depending on the exception.
This change would not just eliminating a throw in strict mode. It is also
change sloppy mode behavior where such assignments have been silently
ignored since ES1. It would be a fundamental change to the meaning of the
[[Writable]] property attribute.
see
http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake (and
links from that page)
also see the recent discussion at
https://github.com/getify/You-Dont-Know-JS/issues/91#issuecomment-38702332
So far we have not been able to reach a consensus on changing this. I
don't know whether report actually adds any new information or whether it
will help develop a consensus.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
Mark S. Miller wrote: This mistake is my single biggest regret from the ES5 days. We had a chance to get this right when it would have been rather painless and we blew it. Indeed, as JSC and (therefore, at the time it was copying semantics) V8 did implement a fix to the override mistake. Have to let this one go, and look to the future. Although it can no longer be fixed without a lot of pain, I still think the pain of not fixing it will be greater. However, I'm sick of arguing about this one and have become resigned to using tamperProof https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#338 rather than freeze. Using tamperProof rather than freeze, your example will work. If enough others become convinced that this still can and should be fixed, we should still fix this. However, someone else would need to volunteer to champion it within TC39. Any volunteers? Wasn't there another idea, which doesn't help code that must run in old browsers, but which could help down the road? I mean the := operator as define-property not put. Didn't we defer that without prejudice? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
I am not sure I understood: is not throwing and a silent failure preferred?
'cause that method won't be there anyway...
I need to write chapter 3 of my quadrilogy of posts related to descriptors
and inheritance* but you can simply avoid that problem via
`Object.defineProperty(Pony.prototype, 'toString', {value: function () {}})`
This will most likely work everywhere except in old mobile browsers such
Palm Pre and Android 2.2 or 2.3, cannot remember, where this bug will show
up:
```javascript
var hasConfigurableBug = !!function(O,d){
try {
O.create(O[d]({},d,{get:function(){
O[d](this,d,{value:d})
}}))[d];
} catch(e) {
return true;
}
}(Object, 'defineProperty');
```
Accordingly, with these browsers the following code will fail:
```javascript
Object.defineProperty(Function.prototype, 'test', {
get: function () {
return Object.defineProperty(this, 'test', {
value: 'OK'
}).test;
}
});
```
but not this one:
```javascript
var proto = {};
Object.defineProperty(proto, 'test', {
get: function () {
if (hasConfigurableBug) {
var descriptor = Object
.getOwnPropertyDescriptor(proto, 'test');
delete proto.test;
}
Object.defineProperty(this, 'test', {
value: 'OK'
});
if (hasConfigurableBug) {
Object.defineProperty(proto, 'test', descriptor);
}
return this.test;
}
});
```
The key is keep properties configurable so that these can be deleted and
put back later on ... although this goes against that feeling of security
`Object.freeze(Object.prototype)` or `Object.freeze(global)` gives us ...
but I still believe that few edge cases a part these operations should be
avoided.
Anyway, please update this thread whenever a decision has been taken so I
can point to this one in one of these posts.
* [part 1](
http://webreflection.blogspot.com/2014/03/what-books-wont-tell-you-about-es5.html
)
[part 2](
http://webreflection.blogspot.com/2014/03/what-books-didnt-tell-you-about-es5.html
)
part 3 with solutions to this problem coming soon
On Wed, Mar 26, 2014 at 11:24 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
use strict;
function Pony() {}
Object.freeze(Object.prototype);
Pony.prototype.toString = function () { return Pony; };
The last line here throws a TypeError in ES5 and ES6.* Can we change
it? To me, it stands to reason that you should be able to freeze
Object.prototype and not break your other code, as long as that code
doesn't actually try to modify Object.prototype.
This bit some Mozilla hackers in http://bugzil.la/980752.
Compatibility: Changing from throwing to not-throwing is usually ok.
In addition, I don't think Chrome implements this TypeError. So
presumably the web can't be depending on the exception.
Patch: Step 5.a of [[Set]] could be changed like from:
a. If ownDesc.[[Writable]] is false, return false.
to:
a. If ownDesc.[[Writable]] is false and O and Receiver are the
same object, return false.
-j
*Why I think it throws:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ordinary-object-internal-methods-and-internal-slots-set-p-v-receiver
Pony.prototype.[[Set]] reaches step 4.c. and tail-calls
Object.prototype.[[Set]], which reaches step 5.a. and returns false.
The TypeError is thrown from step 6.d. of PutValue:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-putvalue
which is called from step 1.f. from AssignmentExpression Evaluation:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-runtime-semantics-
___
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: [[Set]] and inherited readonly data properties
actually `writable:false` is OK, it's only the `get` case that is buggy, as
well as `set`
on Android 2.3.6 (or lower) you can [try this page](
http://www.3site.eu/jstests/configurable.html) which will show an alert like
```
4, // the length
true, // has enumerable bug
OK, // code works anyway deleting in proto
456, // test value is correct
// probably undefined, no idea why is empty
// but the value is not there
```
last test is something like
`Object.create(Object.defineProperty({},'test',{set:Object}),{test:{value:456}}).test`
which won't show `456` in these devices ... it actually does nothing, not
even throwing, it's just undefined.
So, whatever decision will be taken about not writable, if you want to
consider old browsers .. these are ok with `writable:false` because it's
possible to reconfigure them without needing to delete the prototype first.
Sorry for the initial false alarm, at least I am sure few didn't know about
the getters and setters bug in actually quite recent Android 2 browsers.
Best Regards
On Wed, Mar 26, 2014 at 2:10 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I am not sure I understood: is not throwing and a silent failure
preferred? 'cause that method won't be there anyway...
I need to write chapter 3 of my quadrilogy of posts related to descriptors
and inheritance* but you can simply avoid that problem via
`Object.defineProperty(Pony.prototype, 'toString', {value: function () {}})`
This will most likely work everywhere except in old mobile browsers such
Palm Pre and Android 2.2 or 2.3, cannot remember, where this bug will show
up:
```javascript
var hasConfigurableBug = !!function(O,d){
try {
O.create(O[d]({},d,{get:function(){
O[d](this,d,{value:d})
}}))[d];
} catch(e) {
return true;
}
}(Object, 'defineProperty');
```
Accordingly, with these browsers the following code will fail:
```javascript
Object.defineProperty(Function.prototype, 'test', {
get: function () {
return Object.defineProperty(this, 'test', {
value: 'OK'
}).test;
}
});
```
but not this one:
```javascript
var proto = {};
Object.defineProperty(proto, 'test', {
get: function () {
if (hasConfigurableBug) {
var descriptor = Object
.getOwnPropertyDescriptor(proto, 'test');
delete proto.test;
}
Object.defineProperty(this, 'test', {
value: 'OK'
});
if (hasConfigurableBug) {
Object.defineProperty(proto, 'test', descriptor);
}
return this.test;
}
});
```
The key is keep properties configurable so that these can be deleted and
put back later on ... although this goes against that feeling of security
`Object.freeze(Object.prototype)` or `Object.freeze(global)` gives us ...
but I still believe that few edge cases a part these operations should be
avoided.
Anyway, please update this thread whenever a decision has been taken so I
can point to this one in one of these posts.
* [part 1](
http://webreflection.blogspot.com/2014/03/what-books-wont-tell-you-about-es5.html
)
[part 2](
http://webreflection.blogspot.com/2014/03/what-books-didnt-tell-you-about-es5.html
)
part 3 with solutions to this problem coming soon
On Wed, Mar 26, 2014 at 11:24 AM, Jason Orendorff
jason.orendo...@gmail.com wrote:
use strict;
function Pony() {}
Object.freeze(Object.prototype);
Pony.prototype.toString = function () { return Pony; };
The last line here throws a TypeError in ES5 and ES6.* Can we change
it? To me, it stands to reason that you should be able to freeze
Object.prototype and not break your other code, as long as that code
doesn't actually try to modify Object.prototype.
This bit some Mozilla hackers in http://bugzil.la/980752.
Compatibility: Changing from throwing to not-throwing is usually ok.
In addition, I don't think Chrome implements this TypeError. So
presumably the web can't be depending on the exception.
Patch: Step 5.a of [[Set]] could be changed like from:
a. If ownDesc.[[Writable]] is false, return false.
to:
a. If ownDesc.[[Writable]] is false and O and Receiver are the
same object, return false.
-j
*Why I think it throws:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ordinary-object-internal-methods-and-internal-slots-set-p-v-receiver
Pony.prototype.[[Set]] reaches step 4.c. and tail-calls
Object.prototype.[[Set]], which reaches step 5.a. and returns false.
The TypeError is thrown from step 6.d. of PutValue:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-putvalue
which is called from step 1.f. from AssignmentExpression Evaluation:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-runtime-semantics-
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
