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
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
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
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
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,
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
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
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
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},
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 =
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
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
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
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
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
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
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.
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,
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
19 matches
Mail list logo
