Re: A proposal to add String.prototype.format

2011-03-09 Thread Bob Nystrom
It doesn't specify how to print objects, except for %s, which says that if the argument is not a string, convert it to string using .toString(). If the format specifier does not apply to the argument given, it should raise exceptions. Except string conversion, no other conversion will be

Re: That hash symbol

2011-03-29 Thread Bob Nystrom
C#, CoffeeScript, and other languages use - to link a formal parameter list to a function body, which requires bottom-up parsing in general (with comma as operator, as JS, C++, and C have; plus Harmony's destructuring and default parameter value proposals). I'm not a parsing expert, but

Re: Parameter lists as arguments destructuring sugar

2011-04-08 Thread Bob Nystrom
I've implemented an unrelated language that works this way, and it is really nice, but I don't know if moving ES to that after the fact would work. But maybe I'm misreading your proposal. Consider: function show(a, b, c) { log(a + | + b + | + c); } var arg = [1, 2, 3]; show(arg);

Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives

2011-04-18 Thread Bob Nystrom
However, given the reality of ASI, in practice there are two ways to terminate statements. Then the question becomes, what is more usable, optionally turning off ASI, or under prior opt-in to Harmony, improving ASI? I would love to be able to ditch my ; in JS. There are other languages that

Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives

2011-04-19 Thread Bob Nystrom
I think there are a large number of programmers who, because of those java style guidelines and the way ASI works, write javascript breaking before operators except for comma operators. http://www.google.com/codesearch?q=%5Cx20%5Cx20%5Cx20%5B%2B-%5D%5B ^%2B-%5D+lang%3Ajavascript shows

Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives

2011-04-19 Thread Bob Nystrom
var a = 1 + 2 // a = 1 var a = (1 + 2) // a = 3 Ok, so you are advocating that adding extra parens is less typing and less prone to error than adding semicolons? Yes, adding extra parens where needed and omitting ; is less typing. To verify, I just went through a bunch of

Re: I noted some open issues on Classes with Trait Composition

2011-05-18 Thread Bob Nystrom
On Mon, May 16, 2011 at 8:02 AM, Brendan Eich bren...@mozilla.com wrote: On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote: Regarding `new` keyword for the constructor (aka initializer), after all, it als may be OK. E.g. Ruby uses `new` as exactly the method of a class -- Array.new,

Re: prototype for operator proposal for review

2011-05-18 Thread Bob Nystrom
What about making the operator go in the other direction, like so: {a:1,b:2} | MyObject.prototype [0,1,2,3,4,5] | appBehavior Array.create=function(proto,props) { return Object.defineProperties([ ] | proto, props) }; let f = function () {} | EnhancedFunctionPrototype var p = /[a-m][3-7]/ |

Re: I noted some open issues on Classes with Trait Composition

2011-05-18 Thread Bob Nystrom
On Wed, May 18, 2011 at 11:48 AM, Brendan Eich bren...@mozilla.com wrote: The whole of class declaration is a mouthful. 'function' and 'prototype' are overlong too. Agreed. One of the reasons I'm really excited about this proposal is that it addresses those: // old and busted function

Re: I noted some open issues on Classes with Trait Composition

2011-05-18 Thread Bob Nystrom
:) Rick On Wed, May 18, 2011 at 3:10 PM, Bob Nystrom rnyst...@google.com wrote: On Wed, May 18, 2011 at 11:48 AM, Brendan Eich bren...@mozilla.comwrote: The whole of class declaration is a mouthful. 'function' and 'prototype' are overlong too. Agreed. One of the reasons I'm really

Re: I noted some open issues on Classes with Trait Composition

2011-05-18 Thread Bob Nystrom
On Wed, May 18, 2011 at 5:51 PM, Mark S. Miller erig...@google.com wrote: On Wed, May 18, 2011 at 5:17 PM, Bob Nystrom rnyst...@google.com wrote: I believe it would be something like: class Ctor { public method() { return own property; } method() { return instance

Re: I noted some open issues on Classes with Trait Composition

2011-05-19 Thread Bob Nystrom
On Wed, May 18, 2011 at 6:29 PM, Brendan Eich bren...@mozilla.com wrote: On May 18, 2011, at 5:57 PM, Bob Nystrom wrote: class Point { public x = 0, y = 0; } let p = new Point(); p.x; // 0 This is pretty rare, in my experience. I just did some spelunking through some JS code

Re: Function syntax

2011-05-19 Thread Bob Nystrom
On Thu, May 19, 2011 at 8:46 AM, David Griffiths dxgriffi...@gmail.comwrote: For all the talk about what's usable and readable, I haven't seen much mention of empirical testing done with ordinary people... (My sincere apologies if there's some usability test lab for middlingly intelligent

Re: I noted some open issues on Classes with Trait Composition

2011-05-19 Thread Bob Nystrom
On Thu, May 19, 2011 at 10:50 AM, Brendan Eich bren...@mozilla.com wrote: Don't take this the wrong way ;-), but how many of those initializations were immediately overwritten by the constructor, unconditionally or even conditionally? Heh, zero, actually. We're pretty scrupulous here. The 34

Re: I noted some open issues on Classes with Trait Composition

2011-05-19 Thread Bob Nystrom
On Thu, May 19, 2011 at 11:47 AM, Brendan Eich bren...@mozilla.com wrote: Here's another question: how many property initializations could be done straight from the parameter of the same name? Of the 88 fields I looked at, 10 were straight copies of a constructor argument. Another 4 are

Re: I noted some open issues on Classes with Trait Composition

2011-05-19 Thread Bob Nystrom
On Thu, May 19, 2011 at 3:08 PM, Brendan Eich bren...@mozilla.com wrote: class Point { x = 0; ... } is a bit of a mystery. Is it an assignment expression-statement? No, no statements as * ClassElements*. Could it be creating a prototype property, as other unprefixed property

Re: I noted some open issues on Classes with Trait Composition

2011-05-19 Thread Bob Nystrom
On Thu, May 19, 2011 at 5:20 PM, Brendan Eich bren...@mozilla.com wrote: Taken together, I wonder whether we aren't abusing *Declaration* to bind properties. +1. I've been mostly working at this informally and haven't spent much time looking at the EBNF yet, but I'd expect a class body to

Re: I noted some open issues on Classes with Trait Composition

2011-05-19 Thread Bob Nystrom
On Thu, May 19, 2011 at 5:40 PM, Brendan Eich bren...@mozilla.com wrote: Of the 88 fields I looked at, 10 were straight copies of a constructor argument. Another 4 are copies with an if undefined then use this default instead check. ??=, check

Re: I noted some open issues on Classes with Trait Composition

2011-05-20 Thread Bob Nystrom
On Thu, May 19, 2011 at 6:13 PM, Brendan Eich bren...@mozilla.com wrote: On May 19, 2011, at 6:08 PM, Bob Nystrom wrote: And there may be call sites like new SomeClass(undefined, blah) I think most people try to minimize those cases, but they seem to crop up, especially as code accretes

Re: Different semantics should have different-looking syntax

2011-05-21 Thread Bob Nystrom
On Sat, May 21, 2011 at 1:24 PM, Brendan Eich bren...@mozilla.com wrote: It turns out now that it's really a dilemma what to choose -- arrows or blocks... have to think. Arrow function syntax is just syntax. I will drop it if we can agree on block lambda revival. As @_sjs (Sami Samhuri)

Re: Short Functions

2011-05-22 Thread Bob Nystrom
On Sat, May 21, 2011 at 6:39 PM, Brendan Eich bren...@mozilla.com wrote: Really, we're between these choices: 1. Do nothing, function + return 4ever. 2. Shorter function syntax by some abbreviation for 'function' that still requires 'return ' followed by an expression to return a value.

Re: Is class syntax really necessary ?

2011-05-23 Thread Bob Nystrom
1. More syntax means larger language surface, which adds complexity more things to remember / learn. More things to consider in ES.next.next Yup, languages almost always tend to get bigger over time since it's really hard to remove features. For me, the goal isn't to make the language as

Re: Is class syntax really necessary ?

2011-05-23 Thread Bob Nystrom
On Mon, May 23, 2011 at 8:51 AM, Brendan Eich bren...@mozilla.com wrote: Class syntax is like a lint brush for such features. If we add it, it will accrete more semantics (with unambiguous syntax, I hope) over time. This is just inevitable, in my view. It makes me want to resist classes and

Re: Is class syntax really necessary ?

2011-05-23 Thread Bob Nystrom
On Mon, May 23, 2011 at 10:41 AM, Brendan Eich bren...@mozilla.com wrote: On May 23, 2011, at 10:03 AM, Alex Russell wrote: (A) the boilerplate needed to set up a sub-prototype object with correct constructor property, and (B) the pain of doing correct super calls by hand. I hope we

Re: Is class syntax really necessary ?

2011-05-23 Thread Bob Nystrom
Using public to refer to an instance property seems totally weird to me. For what it's worth, I agree. I'd prefer var or instance. I've already seen at least one example of someone misinterpreting it and doing something like: class C { public someMethod() { ... } } Their intent was to

Re: class sugar: static inheritance

2011-06-06 Thread Bob Nystrom
On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux petermich...@gmail.comwrote: Based on my understanding of what the desugared code would be, the last line above would be an error because Dragon.allMonsters is undefined. That's correct. Do you have any examples of code where inheriting the

Re: I noted some open issues on Classes with Trait Composition

2011-06-08 Thread Bob Nystrom
On Tue, Jun 7, 2011 at 1:19 PM, Gavin Barraclough barraclo...@apple.comwrote: Ah, good point, I hadn't considered anonymous classes. Clearly we could solve this with a solution specific to these cases (say, class(){ /*...*/ } for anonymous class constructors?), but having mismatching syntax

Re: Harmony:classes static and private

2011-06-08 Thread Bob Nystrom
Either I'm out-of-date or the wiki page is. My understanding is that at the TC39 meetings we decided to move instance and private record declarations out of the class body and into the constructor. If that's the case, this should be less confusing. You can no longer use public or private at the

Re: class sugar: static inheritance

2011-06-08 Thread Bob Nystrom
On Wed, Jun 8, 2011 at 9:55 AM, Brendan Eich bren...@mozilla.com wrote: We can definitely leave protected out. My seems inevitable was in response to Kam bringing it up via a question that I expect will be frequently asked. I really hope we can. My interest in adding class syntax to JS was

Re: Harmony:classes static and private

2011-06-08 Thread Bob Nystrom
. Is this one incorrect? On Jun 8, 2011, at 11:13 AM, Bob Nystrom rnyst...@google.com wrote: Either I'm out-of-date or the wiki page is. My understanding is that at the TC39 meetings we decided to move instance and private record declarations out of the class body and into the constructor

Re: super, self, and sideways durable vs. template

2011-06-13 Thread Bob Nystrom
On Sun, Jun 12, 2011 at 2:17 PM, Brendan Eich bren...@mozilla.com wrote: But to use the prototypal pattern, you would want something that has been discussed a bit: class elements (class body elements) defining once-per-class-evaluation function, let, and const bindings not as properties, but

Re: Classes: suggestions for improvement

2011-06-13 Thread Bob Nystrom
On Sun, Jun 12, 2011 at 2:38 PM, Brendan Eich bren...@mozilla.com wrote: Something about classes in JS makes me sad, an emotional effect I can't explain fully. philosophical I'm one of the biggest fans of this class proposal, and I feel a twinge of that sadness too. I look at it as JS taking

Re: Classes: suggestions for improvement

2011-06-14 Thread Bob Nystrom
On Tue, Jun 14, 2011 at 1:34 PM, felix feli...@gmail.com wrote: I think that's been considered before. My complaint with it is that Point isn't a prototype. It's a constructor function whose .prototype property is the prototype. In other words, the object bound to the name Point isn't the

Re: Summary: prototypes as classes

2011-06-28 Thread Bob Nystrom
On Tue, Jun 28, 2011 at 3:56 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: (actually in the today's most widely used class-based languages (Java, C#, C++) a class is no an object at all and don't have properties/fields/polymorphic methods/etc. they really are just a scoping mechanism. What

Re: Summary: prototypes as classes

2011-06-28 Thread Bob Nystrom
On Tue, Jun 28, 2011 at 5:19 PM, Axel Rauschmayer a...@rauschma.de wrote: As an aside: - Static methods in Java always felt like a hack, because Java’s creators couldn’t bring themselves to support first-class functions. - Thus: I would much prefer to put Object.* methods into a module (once we

Re: Summary: prototypes as classes

2011-06-28 Thread Bob Nystrom
On Tue, Jun 28, 2011 at 6:38 PM, Brendan Eich bren...@mozilla.com wrote: It's true, classes want to slide down various lower slopes, over time. The lint brush problem, I called it. We on TC39 are obligated to hold the line. Have you seen this occur in practice? My impression from C++ and C#

Re: Summary: prototypes as classes

2011-07-11 Thread Bob Nystrom
I agree with Brendan's replies, but just to add some more color: On Sat, Jul 2, 2011 at 11:46 AM, Angus Croll anguscr...@gmail.com wrote: The concept itself is very simple - a dynamic archetype to be shared by all my instances: my prototype changes, my instances know about it. I would not

Re: An extend operator is a natural companion to |

2011-07-18 Thread Bob Nystrom
On Mon, Jul 18, 2011 at 10:32 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: This is a nice declarative way to describe the per instance state but it turns out it doesn't generalize very well to multiple levels of inheritance. This is an important point. I think the reason most OOP languages

Re: An extend operator is a natural companion to |

2011-07-18 Thread Bob Nystrom
On Mon, Jul 18, 2011 at 3:40 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote: 2. Familiar from other languages and it works about the same here as it does in those Arguably it doesn't. Java/C# static methods are not inherited/over-ridable

Re: An extend operator is a natural companion to |

2011-07-18 Thread Bob Nystrom
On Mon, Jul 18, 2011 at 4:59 PM, Brendan Eich bren...@mozilla.com wrote: The primary purpose of a class is to define the behavior (methods) of instances. It is describing an abstraction over all the possible instances. The behavior of the singleton class object is typically secondary to the

Re: An extend operator is a natural companion to |

2011-07-19 Thread Bob Nystrom
On Mon, Jul 18, 2011 at 6:50 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: But if you were coming from a language where constructors (classes) were real objects with real methods that could reference this and which were inherited by subclass object you might look at the issue quite

Re: An extend operator is a natural companion to |

2011-07-19 Thread Bob Nystrom
On Mon, Jul 18, 2011 at 9:09 PM, Brendan Eich bren...@mozilla.com wrote: On Jul 18, 2011, at 9:02 PM, Rick Waldron wrote: Hey Bob, FWIW... class Point { constructor(x, y) { this.x = x; this.y = y; } zero() { return new Point(0, 0); } unit() { return new

Re: An extend operator is a natural companion to |

2011-07-19 Thread Bob Nystrom
On Tue, Jul 19, 2011 at 11:16 AM, Brendan Eich bren...@mozilla.com wrote: On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote: (It may be that we should use constructor: or static: instead of class:.) Those hurt more. I like class, it is shortest and closest to the keyword that introduces

Re: An extend operator is a natural companion to |

2011-07-19 Thread Bob Nystrom
On Tue, Jul 19, 2011 at 11:23 AM, Brendan Eich bren...@mozilla.com wrote: On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote: // new lets you declare members on new instances. these would presumably be // invoked on the new object before the constructor body is run. new: numAttacks = 0

Re: An extend operator is a natural companion to |

2011-07-19 Thread Bob Nystrom
On Tue, Jul 19, 2011 at 3:45 PM, Brendan Eich bren...@mozilla.com wrote: On Jul 19, 2011, at 3:13 PM, Allen Wirfs-Brock wrote: The plain name; also looks like a useless expression-statement. When we talked some people pretty strongly felt that it was very desirable to be able to explicitly

Re: An experiment using an object literal based class definition pattern

2011-08-05 Thread Bob Nystrom
Particular, if a programmer sets up an editor template that inserts: If we're OK with relying on tooling to type the boilerplate for us, I'm not sure there's much reason to add any new sugar at all. At that point, we could just set up the tools to insert: function classname() {

Re: An experiment using an object literal based class definition pattern

2011-08-05 Thread Bob Nystrom
On Fri, Aug 5, 2011 at 3:29 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: I think the Class function I suggest above could be an answer. But exploring this was my motivation in writing a significant amount of code using my pattern. I personally didn't find it awkward, error-prone, or to

Re: An experiment using an object literal based class definition pattern

2011-08-09 Thread Bob Nystrom
On Mon, Aug 8, 2011 at 3:14 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: function First() {} function Second() {ihis.getCompetitor = function() {/*whatever*/*}} ... First.partner = (new Second).getPartner();//but getPartner is not defined yet First. competitor = (new

Re: Sep 27 meeting notes

2011-09-28 Thread Bob Nystrom
On Tue, Sep 27, 2011 at 10:30 PM, Brendan Eich bren...@mozilla.com wrote: On Sep 27, 2011, at 4:06 PM, Waldemar Horwat wrote: Trying to understand Oliver's objections to the current class proposal. Oliver objects, as do others, to punning (my word) declarative syntax to define object

Re: Sep 27 meeting notes

2011-09-29 Thread Bob Nystrom
On Thu, Sep 29, 2011 at 4:22 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: However, it seems like all the issues we have seen are due to us trying to solve issues that already exist today with prototype based classes. These involve (but are not limited to): 1. Don't let uninitialized

Re: Sep 27 meeting notes

2011-09-30 Thread Bob Nystrom
On Thu, Sep 29, 2011 at 6:20 PM, Brendan Eich bren...@mozilla.com wrote: On Sep 30, 2011, at 1:11 AM, Erik Arvidsson wrote: On Thu, Sep 29, 2011 at 17:08, Bob Nystrom rnyst...@google.com wrote: class Monster { constructor(this.name, this.health) {} I 3 this. It beats the (public name

Re: Sep 27 meeting notes

2011-09-30 Thread Bob Nystrom
On Fri, Sep 30, 2011 at 10:56 AM, Brendan Eich bren...@mozilla.com wrote: On Sep 30, 2011, at 7:12 PM, Bob Nystrom wrote: We want a syntax for properties on the constructor, so is it worth it to specifically forbid that notation outside of the class: section? It's future-proof. Rather do

Re: Sep 27 meeting notes

2011-09-30 Thread Bob Nystrom
On Fri, Sep 30, 2011 at 12:59 PM, Axel Rauschmayer a...@rauschma.de wrote: I wholeheartedly agree with not obsessing about the token count. I’m very sensitive to context in this regard: in some contexts, I don’t mind or even welcome additional tokens, in other contexts I hate them. However,

Re: Sep 27 meeting notes

2011-09-30 Thread Bob Nystrom
On Fri, Sep 30, 2011 at 3:17 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: I'd argue that my pattern also supports #5 as IDE's can recognize the pattern. An imperative class definition of all that most Smalltalk implementations every had and they generally had fine IDEs. I'm not a

Re: Sep 27 meeting notes

2011-09-30 Thread Bob Nystrom
On Fri, Sep 30, 2011 at 3:38 PM, David Herman dher...@mozilla.com wrote: I disagree. The super patterns are really painful and easy to get wrong in existing JS, and the benefits of combining a prototype declaration and constructor declaration in a single form shouldn't be dismissed. It's

Re: Sep 27 meeting notes

2011-09-30 Thread Bob Nystrom
On Fri, Sep 30, 2011 at 4:57 PM, Waldemar Horwat walde...@google.comwrote: On 09/30/2011 04:37 PM, Brendan Eich wrote: since we haven't come up with a way to do 2 and 5 that works, That's what makes this into a dead end. Worse, by claiming the class syntax you'd be precluding finding a

Re: On I got 99 problems and JavaScript syntax ain't one

2011-10-04 Thread Bob Nystrom
On Tue, Oct 4, 2011 at 10:52 AM, Mikeal Rogers mikeal.rog...@gmail.comwrote: My main concern with *some* of the proposals is that I feel they add features and clever syntax for experts at the expense of keeping the language easy to understand for new programmers. It's hard to satisfy both

Re: On I got 99 problems and JavaScript syntax ain't one

2011-10-04 Thread Bob Nystrom
On Tue, Oct 4, 2011 at 2:12 PM, John J Barton johnjbar...@johnjbarton.comwrote: On Tue, Oct 4, 2011 at 12:59 PM, Bob Nystrom rnyst...@google.com wrote: A constructor is different from a regular function. Instead of returning the value that the body of the function returns, it returns

Re: On I got 99 problems and JavaScript syntax ain't one

2011-10-05 Thread Bob Nystrom
On Wed, Oct 5, 2011 at 7:18 AM, John J Barton johnjbar...@johnjbarton.comwrote: On Tue, Oct 4, 2011 at 2:33 PM, Bob Nystrom rnyst...@google.com wrote: That's correct. That's often the cost of concision. By analogy: you can do a lot of stuff using either an explicit stack data structure

Re: On I got 99 problems and JavaScript syntax ain't one

2011-10-10 Thread Bob Nystrom
On Mon, Oct 10, 2011 at 1:33 PM, Dean Landolt d...@deanlandolt.com wrote: On Wed, Oct 5, 2011 at 1:40 PM, Bob Nystrom rnyst...@google.com wrote: On Wed, Oct 5, 2011 at 7:18 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Tue, Oct 4, 2011 at 2:33 PM, Bob Nystrom rnyst

Re: Alternative syntax for |

2011-11-22 Thread Bob Nystrom
On Tue, Nov 22, 2011 at 10:41 AM, Brendan Eich bren...@mozilla.com wrote: Nothing there about arrays or regular expressions, and the function examples do *not* show anything like superFun | function (...) {...} Instead of Ahem'ing, could you cite what you claim is a prior proposal with

Re: Anonymous methods

2012-01-11 Thread Bob Nystrom
On Wed, Jan 11, 2012 at 10:10 AM, John J Barton johnjbar...@johnjbarton.com wrote: The blog post http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ makes the case for blocks that act like functions when passed as arguments but have loop-up rules more like nested blocks. Of course

Re: Class declarations

2012-03-16 Thread Bob Nystrom
On Fri, Mar 16, 2012 at 10:48 AM, Brendan Eich bren...@mozilla.org wrote: Not hermeneutic spirals, just circles. Feels like the last year (we cut off ES6 proposals, modulo exceptions/tweaks, last May; we had a big-ish classes strawman synthesized from several prior proposals; we lost Bob

Re: Class declarations

2012-03-16 Thread Bob Nystrom
On Fri, Mar 16, 2012 at 4:22 PM, Brendan Eich bren...@mozilla.org wrote: And properties can be used before initialization in JS today (and in Dart -- you Google guys are not all following the same rules :-P). This is definitely the strangest possible venue for discussing Dart, but... That

Re: Finding a safety syntax for classes

2012-03-20 Thread Bob Nystrom
On Mon, Mar 19, 2012 at 1:03 PM, Russell Leggett russell.legg...@gmail.comwrote: The recent discussion “Using Object Literals as Classes” brought up some key points, but the general feeling I got and agree with is this: we need to get classes into ES6. As Kevin points out, even if it didn’t

Re: Classes as Cosntructors

2012-05-22 Thread Bob Nystrom
I think this is really interesting. This will look like I'm poking holes here, but please don't take that to mean that I don't find the overall approach worth investigating. You can consider anything I *don't *poke at to be a sign of approval. Some concerns: *It looks like methods on the