Re: Octal literals have their uses (you Unix haters skip this one)

Fri, 13 Jan 2012 10:15:30 -0800

January 13, 2012 1:30 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

/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

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
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

Reply via email to