As an aside: love how class is used in "Point extends SomeBaseClass", below (including "class.lastPoint").
> From: Brendan Eich <[email protected]> > Subject: Re: Sep 27 meeting notes > Date: September 30, 2011 20:53:33 GMT+02:00 > To: Erik Arvidsson <[email protected]> > Cc: es-discuss <[email protected]> > > My question for everyone: will users expect declared property names to be > in-scope, no matter what the syntax for declaring or defining them is? I > suspect so, and that makes me think we're not going to do well by > "counter-steering" with object literal property init syntax. I consider myself a Java head, but I never liked member variables coming into the scope of methods. The explicitness and symmetry (when having an argument whose type is the same as that of "this") it brings are great. For me, regularity is more important for my brain’s decoding speed than seeing less characters. Instance property init syntax seems like a bad idea. I’m often seeing people using prototype properties for this purpose, which works but feels wrong. It gives people the wrong idea. It’s best to tell newbies: Forget most of what you know about classes and stick to the following rules: 1. Everything that goes into the instance must be put inside the constructor. 2. Methods that are shared between instances go into the prototype. 3. Class methods go into the "class:" section. #1 goes against the grain of the Java school of thought, but it is very logical once you accept it. And (especially with "this." in the parameter declaration) it avoids redundancies such as: class Point { public int x; public int y; public Point(int x, int y) { this.x = x; this.y = y; } } I’m still slightly worried about correspondences: Given the code below, Point is a function, but "add(other)" is not one of its methods. The way that the default (epsilon section) is currently handled suggests that Point is the prototype object (it even has a method called "constructor"…). I see two solutions: 1. Properties in the default (epsilon) section become class properties. Probably not a good idea, because it would thoroughly confuse people coming from other languages. 2. Require a prototype: section for methods. I’m not entirely happy with #2, either. Maybe there is some other way to achieve this—it would be nice that if people dug a little deeper (e.g. examining what’s inside Point), what they found conformed to the expectations they have from working with class literals. > class Point extends SomeBaseClass { > // Constructor. > constructor(this.x, this.y) { > class.lastPoint = this; > } > > // Constant on prototype: not supported > // Data property on prototype: not supported > > // Function on prototype. > add(other) { > return new Point(this.x + other.x, this.y + other.y); > } > > class: > // Constant on class. > const ZERO = new Point(0, 0); > > // Data property on class. > var lastPoint = undefined; // or let > > // Nested class (data property on class whose value is a class). > class Foo { > ... > } > > // Function on class. > add(a, b) { > return a.add(b); > } > } -- Dr. Axel Rauschmayer [email protected] twitter.com/rauschma home: rauschma.de blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
