Re: standardizing Error.stack or equivalent
Just curious: do you have any particular parts of #1 in mind that could be simplified? c On Tue, Mar 25, 2014, at 01:49 PM, Mark S. Miller wrote: Not only would I hope for all of this in ES7, I would add 5) sourcemaps 6) sourcemap extension to template strings, as in that old email 7) The sourceURL as explained at [1]https://developers.google.com/chrome-developer-tools/docs/javascrip t-debugging#breakpoints-dynamic-javascript or something with equivalent functionality. The main thing needed to get this into ES7 is a champion who will put in the time needed. That ain't me, but I'd be happy to help. Btw, if I were looking to drop something from the list, I'd look first to simplify #1. On Tue, Mar 25, 2014 at 1:39 PM, John Lenz [2]concavel...@gmail.com wrote: Interesting sourcemap usage. But is there any hope for standardization of the existing stack handling for ES7? It wasn't clear to me why it stalled for ES6. There a few things I would like to see: 1) standardization V8's Error.captureStackTrace API 2) standardization of the stack format 3) standardizaton of when the stack is added to the Error object (creation vs throw) 4) specification as to whether throw (and re-throw) overwrite any existing stack property More would be welcome but that is what I would actually have an immediate use for. On Tue, Mar 25, 2014 at 11:43 AM, Mark S. Miller [3]erig...@google.com wrote: Hi John, see also my message at [4]https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.htm l which cites some of your work on sourcemaps. On Tue, Mar 25, 2014 at 11:25 AM, Rick Waldron [5]waldron.r...@gmail.com wrote: On Tue, Mar 25, 2014 at 1:38 PM, John Lenz [6]concavel...@gmail.com wrote: I was recently modifying some code to be strict mode compliant and it reminded me that the primary use of the Function caller property and arguments.caller is to build stack traces. Now the latest Internet Explorer releases have support for stack traces, as of course do Chrome, FF, and Safari but only Chrome/V8, to my knowledge, has an actual API. I know there was some initial work in this area and nothing is likely to happen in the ES6 time frame but can something to be done to make the stacks traces more usable? Take a look at the work Erik Arvidsson has done so far: [7]http://wiki.ecmascript.org/doku.php?id=strawman:error_stack Rick ___ es-discuss mailing list [8]es-discuss@mozilla.org [9]https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list [10]es-discuss@mozilla.org [11]https://mail.mozilla.org/listinfo/es-discuss References 1. https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript 2. mailto:concavel...@gmail.com 3. mailto:erig...@google.com 4. https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html 5. mailto:waldron.r...@gmail.com 6. mailto:concavel...@gmail.com 7. http://wiki.ecmascript.org/doku.php?id=strawman:error_stack 8. mailto:es-discuss@mozilla.org 9. https://mail.mozilla.org/listinfo/es-discuss 10. mailto:es-discuss@mozilla.org 11. https://mail.mozilla.org/listinfo/es-discuss ___ 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
article on ES6 and Traceur
Here's an article I wrote recently that may be of interest. It covers automating the use of Traceur to generate ES5 code. http://sett.ociweb.com/sett/settApr2014.html -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
