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
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
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
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
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
8 matches
Mail list logo
