An "extend" operator is a natural companion to <|

Bob Nystrom rnystrom at
Tue Jul 19 11:37:30 PDT 2011

On Tue, Jul 19, 2011 at 11:16 AM, Brendan Eich <brendan at> 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 the binding (in the named form, not for class expressions --
> but those want a connection back to the keyword too).

I like class too.

>   numAttacks = 0;
>   // declaring an instance property here mainly so you can document it.
> could be
>   // useful later for guards or other annotations.
>   name;
> Neat idea, although the assignment expression-statement appearance still
> rankles. It looks like statements are allowed there, rather than declaration
> forms of some sort. OTOH we are talking about properties, and declarations
> are in lexical binding forms if you exclude object literal property
> assignments from "declarations".

Yeah, I don't like things that look like bare assignment either. I know Mark
isn't a fan, but I'd consider:

  var numAttacks = 0;
  var name;

Or maybe let. I like leading with some keyword.

> Not sure we need 'new' there given lack of private prototype properties in
> the proposal. It's a bit verbose. Probably even if we add private prototype
> properties we can let private: (in this idea you've pitched) default to
> private instance.

That works for me.

> No, don't <shrug>, <cheer>. I think what you've suggested here is strictly
> better than (a) over-indenting one or another group of elements; (b) putting
> "instance variable" declarations in magic syntax in the constructor body;
> (c) festooning one's class declaration with repeated "static" prefix
> keywords.


I think this wins, so far. This does suggest we rushed classes in
> prematurely.

Well if we hadn't started covering the design space, we might not have
gotten here ever, so I'd consider it time well spent.

>  I'm not saying anything more than that we should take our time and avoid
> marrying the syntax in the proposal. We already have agreed that
> private(this), private(foo), etc. is straw to burn up.

Yeah, we'll have to let this marinate a bit and see if we like it. If I can
find some time, I'll try converting a non-trivial chunk of JS to use this
syntax and see how it looks in practice.

- bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list