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: standardizing Error.stack or equivalent
John did you want to propose an alternative? Maybe: A name parameter for inline scripts and eval? This might work for sourceUrl but might be limiting for soureMappingUrl. On Sun, Mar 30, 2014 at 6:25 PM, John Barton johnjbar...@google.com wrote: Hi Mark. I implemented the first sourceURL support, for Firebug back in the day. It's a kludge we worked out because there was no alternative. It forces debuggers seek the ends of buffers even if they are millions of bytes and even if the the name does not turn out to be the one the dev was interested in. It forces developers to use a whacky naming 'API' involving funky characters and special strings. //# sourceURL woulds well in Firebug, Chrome Devtools, and IE as far as I know. It fails in Chrome devtools in two cases, for early compiles before devtools is opened (known limitation) and when using the relatively new devtools workspaces in some complicated cases. Otherwise you should report bugs if it fails for you. When new API arrives we don't have to miss the opportunity to do better. Your references also include source-map discussion which uses same kludgy API. Based on my experience, I think the low reliability of source-maps is partly due to difficulty in testing and reporting bugs with the generated maps. I thought the maps I created for traceur were fine, but later I discovered that the ends of ASTs were not handled correctly but all the user can observe is the sourcemap gives wacky results, sometimes. jjb On Fri, Mar 28, 2014 at 11:55 AM, Sebastian Zartner sebastianzart...@gmail.com wrote: Hi John, supposedly https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript and http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl document the emerging de facto std for providing this name to the existing API. However, I have not seen it work on any browser. See point #5 at https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html. Am I doing something wrong here that account for my not seeing this, or does it in fact not work anywhere? sourceURL and displayName are also working in Firefox. Not consistently yet, though. FWIW Firebug is making use of these in it's 2.0 alpha 1 version. See http://www.softwareishard.com/blog/firebug/firebug-2-support-for-dynamic-scripts/ . Would be great if these could be standardized. Sebastian ___ 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
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: standardizing Error.stack or equivalent
My goal is more modest: to ensure that Loader/System function(s) that accept strings defining JS allow name parameters. We should also work out how to include source-maps. The loader has the right position to obtain the sourcemap from the server or from transcoders. If we have API on the loader to tell the debugger about the map we can have a much more flexible solution. On Mon, Mar 31, 2014 at 8:43 AM, John Lenz concavel...@gmail.com wrote: John did you want to propose an alternative? Maybe: A name parameter for inline scripts and eval? This might work for sourceUrl but might be limiting for soureMappingUrl. On Sun, Mar 30, 2014 at 6:25 PM, John Barton johnjbar...@google.comwrote: Hi Mark. I implemented the first sourceURL support, for Firebug back in the day. It's a kludge we worked out because there was no alternative. It forces debuggers seek the ends of buffers even if they are millions of bytes and even if the the name does not turn out to be the one the dev was interested in. It forces developers to use a whacky naming 'API' involving funky characters and special strings. //# sourceURL woulds well in Firebug, Chrome Devtools, and IE as far as I know. It fails in Chrome devtools in two cases, for early compiles before devtools is opened (known limitation) and when using the relatively new devtools workspaces in some complicated cases. Otherwise you should report bugs if it fails for you. When new API arrives we don't have to miss the opportunity to do better. Your references also include source-map discussion which uses same kludgy API. Based on my experience, I think the low reliability of source-maps is partly due to difficulty in testing and reporting bugs with the generated maps. I thought the maps I created for traceur were fine, but later I discovered that the ends of ASTs were not handled correctly but all the user can observe is the sourcemap gives wacky results, sometimes. jjb On Fri, Mar 28, 2014 at 11:55 AM, Sebastian Zartner sebastianzart...@gmail.com wrote: Hi John, supposedly https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript and http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl document the emerging de facto std for providing this name to the existing API. However, I have not seen it work on any browser. See point #5 at https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html. Am I doing something wrong here that account for my not seeing this, or does it in fact not work anywhere? sourceURL and displayName are also working in Firefox. Not consistently yet, though. FWIW Firebug is making use of these in it's 2.0 alpha 1 version. See http://www.softwareishard.com/blog/firebug/firebug-2-support-for-dynamic-scripts/ . Would be great if these could be standardized. Sebastian ___ 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
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
