Re: Octal literals have their uses (you Unix haters skip this one)
To me this seems like an exception rather than a common problem. Most APIs / tools don't use octals for this type of thing. Seems unnecessary to add to the language for this one use case. Not a Linux hater by any means, just the parseInt thing doesn't bother me for this one situation. Or am I wrong and there are other common uses for octal literals? On Thu, Jan 12, 2012 at 2:51 PM, Wes Garland w...@page.ca wrote: 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 On 12 January 2012 14:11, Brendan Eich bren...@mozilla.com wrote: [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 es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ 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: Octal literals have their uses (you Unix haters skip this one)
Given that octals are likely here to stay, I think they should look as specialized as they are, so a very conspicuous prefix like 0o really makes sense to me. As to which prefix to use, o seems the easiest to remember. On Thu, Jan 12, 2012 at 3:57 PM, Brendan Eich bren...@mozilla.com wrote: No, let's not do everything. That's a bad way to make standards. We should acknowledge that octal is used in JS today and it'll die hard in certain quarters. I don't think this was considered carefully when the decision to ban octal in strict mode was made. If we want to support octal in strict mode, we can certainly ban crazy noctal (08, 09). If we choose to prefix, we should pick one prefix (and it should almost certainly be the same one in Python, Ruby, and CoffeeScript: 0o). Binary is plausible (0b), but after that I see no need for arbitrary-radix literals. /be ___ 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: Array.prototype.contains
I see Array.contains as a great idea. This is an operation I use constantly
when I write code and it'd be nice to have it be a first class Array
operation. Sure it's not so different than indexOf, but the semantics are
much more intuitive and it may very well be the more common operation.
-Greg
On Fri, Dec 30, 2011 at 6:29 PM, Rick Waldron waldron.r...@gmail.comwrote:
That's what I figured - I guess I thinking of implementations that would
be ES3 5 compat
Thanks!
On Fri, Dec 30, 2011 at 6:26 PM, Brendan Eich bren...@mozilla.com wrote:
Jason doesn't want a wrapper written in JS that depends on the current
value of this.indexOf, I think. That's enough reason for a built-in. This
is a no-brainer for ES6 IMHO.
/be
- Original Message -
From: Rick Waldron waldron.r...@gmail.com
To: Jason Orendorff jason.orendo...@gmail.com
Cc: es-discuss es-discuss@mozilla.org
Sent: Friday, December 30, 2011 2:28:28 PM
Subject: Re: Array.prototype.contains
On Fri, Dec 30, 2011 at 5:24 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Fri, Dec 30, 2011 at 6:58 AM, Xavier MONTILLET
xavierm02@gmail.com wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:string_extras
There is a proposal for String.prototype.contains so why can't I find
one for Array.prototype.contains?
No kidding. I need this method every time I write ECMAScript code.
What I want is like:
Object.defineProperty(Array.prototype, contains, {
configurable: true,
writable: true,
value: function contains(x) {
return this.indexOf(x) !== -1;
}
});
except without the property lookup for indexOf.
At this.indexOf ? Or the whole this.indexOf(x) !== -1; lookup? How else
could it work?
Rick
-j
___
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
___
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: Suggestion: Array.prototype.repeat
What is the use case for .repeat? Trying to imagine some code where I'd need it so I can get a feel for how it should work. On Tue, Jan 3, 2012 at 9:19 AM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: Rick Waldron wrote: On Tue, Jan 3, 2012 at 3:34 AM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: Rick Waldron wrote: On Mon, Jan 2, 2012 at 3:56 PM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: I like it, it indeed looks very logical, however it's a bit controversial that we need to create temporary array object to get one that we want. Is the controversy editorial or fact, because the following methods are all specified to use a temporary, newly initialized Array internally: Array.prototype.concat Array.prototype.filter (...) Rick, you say that apart of output arrays this methods create some other temporary arrays internally ? I don't see anything like that in specification, where exactly is it stated ? Array.prototype.concat - http://es5.github.com/#x15.4.4.4 #2 Array.prototype.filter - http://es5.github.com/#x15.4.4.20 #6 (...) Rick, those arrays become result of each method, they're not temporary. - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Suggestion%3A-Array.prototype.repeat-tp33067649p33072157.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ 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: Array.prototype.contains
Sorry I meant Array.prototype.contains
On Tue, Jan 3, 2012 at 9:46 AM, Greg Smith g...@bocoup.com wrote:
I see Array.contains as a great idea. This is an operation I use
constantly when I write code and it'd be nice to have it be a first class
Array operation. Sure it's not so different than indexOf, but the semantics
are much more intuitive and it may very well be the more common operation.
-Greg
On Fri, Dec 30, 2011 at 6:29 PM, Rick Waldron waldron.r...@gmail.comwrote:
That's what I figured - I guess I thinking of implementations that would
be ES3 5 compat
Thanks!
On Fri, Dec 30, 2011 at 6:26 PM, Brendan Eich bren...@mozilla.comwrote:
Jason doesn't want a wrapper written in JS that depends on the current
value of this.indexOf, I think. That's enough reason for a built-in. This
is a no-brainer for ES6 IMHO.
/be
- Original Message -
From: Rick Waldron waldron.r...@gmail.com
To: Jason Orendorff jason.orendo...@gmail.com
Cc: es-discuss es-discuss@mozilla.org
Sent: Friday, December 30, 2011 2:28:28 PM
Subject: Re: Array.prototype.contains
On Fri, Dec 30, 2011 at 5:24 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Fri, Dec 30, 2011 at 6:58 AM, Xavier MONTILLET
xavierm02@gmail.com wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:string_extras
There is a proposal for String.prototype.contains so why can't I find
one for Array.prototype.contains?
No kidding. I need this method every time I write ECMAScript code.
What I want is like:
Object.defineProperty(Array.prototype, contains, {
configurable: true,
writable: true,
value: function contains(x) {
return this.indexOf(x) !== -1;
}
});
except without the property lookup for indexOf.
At this.indexOf ? Or the whole this.indexOf(x) !== -1; lookup? How
else could it work?
Rick
-j
___
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
___
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: Alternative syntax for |
The biggest advantage to beget is that it has the opportunity to become The
Prototype Word. inherit has a lot of people associating it with classical
OO programming. As nice as inherit sounds, it might be good to drop that
baggage.
-Greg
On Wed, Nov 16, 2011 at 2:31 PM, Rick Waldron waldron.r...@gmail.comwrote:
As stated previously[1], my support for begets as pure win is unwavering.
Rick
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-October/017758.html
On Wed, Nov 16, 2011 at 2:16 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On 16.11.2011 23:12, Erik Arvidsson wrote:
One thing that all of these discussions are missing is the hoisting
property of function and any possible future classes. If we use let
Point = ... we lose all hoisting and the order of your declarations
starts to matter and we will end up in the C mess where forward
references do not work.
No matter, we may rewrite it with `var':
// parent object
var point = {x: 10, y: 20};
// child object
var point3D extends point {
z: 30
}
// a class
class Point3D extends Point {
constructor (x, y, z) { ... }
}
It seems interesting for me, since we define both -- child classes and
child objects with the same syntactic construction; only `var' and `class'
keywords change.
Dmitry.
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
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: On class literals possibly not making it into ECMAScript.next
Hi, I've been lurking on this mailing list for awhile but just wanted to
speak up to say that I think Axel sums up a lot of my feelings about
JavaScript and classes. Sorry if I'm speaking out of turn and without
context, just wanted to throw my thoughts out there anyway.
Anyway, prototypes are good and object literals are good. I think a lot of
the class love is about syntax: they are tidy and self-evident. Object
literals are also tidy and self-evident. Prototypes are just messy as they
stand in JS. I've taken to enjoying a pattern where you can use object
literals to define objects and still get inheritance using prototypes.
You've probably seen this type of thing before:
var Person = Animal.inherit({
getName: function() {
return this.name;
}
});
var bob = Person.inherit({
name: 'Bob'
});
bob.getName(); // Bob
I have some code to provide this type of pattern here
https://github.com/incompl/super-inherit/blob/master/demo.js
But what I'm really getting at is that I think if JavaScript made it this
neat and tidy to do prototypal inheritance there might be less clamoring
for classes.
Also, I think having super would help a lot.
Anyway that's my two cents.
-Greg
On Sat, Oct 29, 2011 at 7:03 PM, Axel Rauschmayer a...@rauschma.de wrote:
There are two things is JavaScript that are simple and elegant and
universally liked:
- Prototypes
- Object literals
How come we can’t transport that simplicity to classes? Once the objects
have been created, we are happy with them, but how to best set them up is
still controversial. Are we overthinking classes?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
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
