Le 13/01/2012 19:15, Brendan Eich a écrit :
Lasse Reichstein:
It might be changed if there was an actual advantage
for the programmers in using strict mode, which there
hasn't been
I heard some got burnt by a missing "var" [1]. Strict mode and a bit
of testing could have prevented this blog post from existing.
If strict mode only had introduced this change, I would consider it
worthwhile.
Yes, that alone is worth a lot. But strict mode has a bad rep and these
folks did not use it. We should look directly at why.
it's not faster, it's not simpler, and it's not what
they are used to
I recently suggested a newcomers to the language to always be in
strict mode ;-)
Great. Not happening enough at scale to matter, AFAICT. I could be
wrong, it's early yet. But we can't use strict-mode adoption as an
argument against default version (unversioned script, new syntax as its
own opt-in) being the norm.
and being more compatible between ECMAScript
implementations makes no difference when writing for just
node.js.
This part I agree with. Strict mode did some good things we like
(all the early errors, basically). The runtime meaning shifts and
their implications for performance (at least, without new
optimization effort on the part of implementors, who face little
incentive without adoption -- which won't be forthcoming without
performance) were not good.
Regarding performance, I'm not sure I understand what the big deal
is. It's always possible to develop in strict mode and deploy as
non-strict if the performance difference really matters.
Code written with in strict mode and with decent discipline (not
assuming anything on the 'this' value of a function used as a
function, for instance, etc.) should run fine in non-strict, no?
It's not just |this| coercion. If you write code that assumes no
arguments aliasing and assign to a formal parameter or arguments[i] that
aliases it in non-strict mode, and do not get the aliasing (as you
expect), but fail to test your non-strict deployed code, you have a
subtle and possibly nasty bug.
People won't take such risks without better-communicated incentives,
even though the cases are "corner cases". The main selling point as you
note is assigning to a free variable is a runtime error. That's good but
not great. Harmony (however opted-in) makes it an early error, which is
the real deal.
/be
January 13, 2012
10:15 AM
I'd like
having 0o777 (and 0b1111!) but I thought the reason for removing the
existing octal literals was that they were surprising and error-prone
(and behaving erratically in different settings, so, e.g., 0100 !=
+"0100").
That reasoning still stands.
Are there bug reports or other skidmarks from mistakes of this kind?
I've never seen one.
https://bugzilla.mozilla.org/buglist.cgi?field0-0-5=content&am
p;type0-0-4=substring&type0-0-5=matches&value0-0-5=%22octal%22&list_id=2058643&short_desc=octal&field0-0-0=product&type0-0-1=substring&field0-0-1=component&type0-0-6=substring&field0-0-4=status_whiteboard&classification=Components&value0-0-2=octal&field0-0-6=cf_crash_signature&query_format=advanced&type0-0-3=substring&field0-0-3=short_desc&value0-0-3=octal&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&value0-0-4=octal&short_desc_type=allwordssubstr&field0-0-2=alias&value0-0-1=octal&type0-0-0=substring&value0-0-6=octal&value0-0-0=octal&component=_javascript_%20Engine&product=Core&type0-0-2=substring
Indeed we made bugs for our users in the course of implementing and
finalizing ES5. Here's a particularly time-killing exercise:
https://bugzilla.mozilla.org/show_bug.cgi?id=601262
I don't think people writing non-strict code as
their default for node.js is a problem solved by changing strict mode.
Harmony is based on strict mode. V8 is implementing Harmony proposals
for ES.next. The recent version-free opt-in thinking in concert with
these facts suggest Node.js people will be writing ES.next code at some
point. Will octal permission literals work then? It's a small point but I
say they ought to.
It might be changed if there was an actual advantage for
the programmers in using strict mode, which there hasn't been - it's not
faster, it's not simpler, and it's not what they are used to, and being
more compatible between ECMAScript implementations makes no difference
when writing for just node.js.
This part I agree with. Strict mode did some good things we like (all
the early errors, basically). The runtime meaning shifts and their
implications for performance (at least, without new optimization effort
on the part of implementors, who face little incentive without adoption
-- which won't be forthcoming without performance) were not good.
/be
January 12, 2012
10:47 PM
The API in question takes a
string and does parseInt if necessary. That's not the issue. There is
real code using octal and it won't change to quote the numeric literal,
and it won't adopt strict mode. Meanwhile CoffeeScript is trying to
target strict mode. It can cope, but we're left with non-strict Node.js
JS source code as default, with no incentive to change.
What was the good, what benefit was achieved, by banning octal from
strict mode? Since it is required for web compatibility, it is already
in the spec. Adding 0o is not adding an unnecessary feature if there are
valid use cases for octal. Or would you be ok if we simply allowed
0-prefixed octal in strict mode?
/be
January 12, 2012
10:15 PM Seems
like a library
interface that isn't well thought through:
Accepting a number as
input, but it's only reasonably written in one
base. Then it's not
really a number, but rather a formatted string, so
the chmod function
should take a string as argument and do its own
parseInt(_,8) on it
(and accept other formats too, like "a+rw" or
"rwxr--r--").
Don't
try to fix a single broken interface by adding unnecessary
features
to the language!
/L 'not a Unix hater, but probably a chmod hater'
January 12, 2012
11:51 AM I'll chime in
with my vote - I
would LOVE to be able to use octal literals again in GPSEE for setting
file permissions.
chmod("filename", parseInt("777", 8))
^^^^
just looks stupid when chmod("filename", 0777) would work just fine.
Wes
--
Wesley W. Garland
Director,
Product Development
PageMail, Inc.
+1 613 542 2787 x 102
January 12, 2012
11:11 AM [Resending
reply with
elaboration. /be]
Yes, the ability to quote the octal literal with Node's APIs came up
on
the gist, but it's not enough.
Quoting is easy to forget, and making the runtime convert string
(literal) to number is inefficient compared to having JS do it at
compile-time, and making the runtime (even via a call to parseInt) do it
also increases bug habitat ever so slightly.
Mainly, users don't have to shun octal in non-strict mode, and they
do
not in Node code I have seen. They won't be adopting strict mode as far
as I can tell. Banning octal is just one more reason for those who
*might* adopt strict mode to reject it.
Agree on parseInt. Old dog, hard to change (runtime-only errors are
migration- and user-hostile). Not sure what to do there.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
I'd like having 0o777 (and
0b1111!) but I thought the reason for removing the existing octal
literals was that they were surprising and error-prone (and behaving
erratically in different settings, so, e.g., 0100 != +"0100").
That reasoning still stands.
I can't say whether
removing them from strict mode was really a benfit. It made strict mode
more compatible across browsers than non-strict mode ever was, but it
might also have made moving code from non-strict to strict slightly
harder.
Personally, I'd go for strict mode to be sure that my numbers were
*not* interpreted as octal. But that's what's being argued
here - converting existing code (or existing programmers) to strict mode
is hampered by them not being able to use the octal numbers they are
used to.
Well, these are obviously not programmers that want
strict mode to begin with (since it requires very little effort to
change the octal literal to a string). It's people that would choose
strict mode only if it was trivial or they had a compelling reason for
doing it.
I don't think people writing non-strict code as
their default for node.js is a problem solved by changing strict mode. It
might be changed if there was an actual advantage for the programmers
in using strict mode, which there hasn't been - it's not faster, it's
not simpler, and it's not what they are used to, and being more
compatible between ECMAScript implementations makes no difference when
writing for just node.js.
/L
January 12, 2012
10:47 PM
The API in question takes a
string and does parseInt if necessary. That's not the issue. There is
real code using octal and it won't change to quote the numeric literal,
and it won't adopt strict mode. Meanwhile CoffeeScript is trying to
target strict mode. It can cope, but we're left with non-strict Node.js
JS source code as default, with no incentive to change.
What was the good, what benefit was achieved, by banning octal from
strict mode? Since it is required for web compatibility, it is already
in the spec. Adding 0o is not adding an unnecessary feature if there are
valid use cases for octal. Or would you be ok if we simply allowed
0-prefixed octal in strict mode?
/be
January 12, 2012
10:15 PM Seems like a library
interface that isn't well thought through:
Accepting a number as
input, but it's only reasonably written in one
base. Then it's not
really a number, but rather a formatted string, so
the chmod function
should take a string as argument and do its own
parseInt(_,8) on it
(and accept other formats too, like "a+rw" or
"rwxr--r--").
Don't
try to fix a single broken interface by adding unnecessary
features
to the language!
/L 'not a Unix hater, but probably a chmod hater'
|
