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 less and get it right than over-reach and regret
the stuff that we got wrong.
> If we did want to go down the path of a more rigid class pattern (i.e. no
> data props on prototype, etc.) then I think we could support all of the
> combinations we care about with a pretty terse notation:
>
> class Point extends SomeBaseClass {
> // Constructor.
> constructor(this.x, this.y) {
> class.lastPoint = this;
> }
>
> // Constant on class.
> const ZERO = new Point(0, 0);
>
> // Data property on class.
> var lastPoint = undefined; // or let
>
> // Function on class.
> class add(a, b) {
> return a.add(b);
> }
>
> // Nested class (data property on class whose value is a class).
> class Foo {
> ...
> }
>
> // 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);
> }
> }
>
> This gets rid of sections, and gets rid of "static" by using "class" instead.
> It avoids the "class class" problem for nested classes by declaring by fiat
> that a nested class goes on the constructor.
>
> Thoughts?
I like that nested class is "static" or rather, a property of the outer class's
constructor.
This has the irregularity you objected to in the ES4/Oliver "data properties on
instances, methods on prototype", but with data properties on the class instead
of the instance.
And this is future-hostile to data properties on the prototype, something
you're right to consider supporting. Using a class: section is
future-friendlier and not much of a hardship.
Try this:
class Point extends SomeBaseClass {
// Constructor.
constructor(this.x, this.y) {
class.lastPoint = this;
}
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 {
...
}
prototype:
// Function on class.
class add(a, b) {
return a.add(b);
}
// 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);
}
}
Supporting a prototype: label to allow alternation for minimal change under
maintenance is plausible.
For now I think we should minimize and future-proof by forbidding data
declarations in the prototype section (the default, implicit section without
any label).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
