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 prototype can access constructor arguments
when they can't.* I worry that users would expect this to work:
class Rect(width, height) {
public area() { return width * height; }
}
*Mixing statements and definitions together may be future-hostile.* One
thing I like about other class approaches is the a class body can only
contain a specific whitelist of allowed definitions. That lets us wipe a
corner of the syntax clean so that we have room to fill it in later with
other kind of definitions (const, class properties, nested classes,
insert-your-pet-feature-here, etc.). Letting arbitrary statements in gives
us a lot less breathing room.
This is, I think, one of the fundamentally hard things about class syntax.
There's basically three clumps of code users need to write in order to
define a class: the constructor, the prototype properties and the class
properties. Our (valid!) desire for simplicity encourages us to reduce that
but it's really hard to do without just muddling stuff together.
We can probably punt on class properties (at least for now), but that still
leaves either a "two adjacent curly block" approach like a lot of the .{
proposals, a "class body containing a constructor body" approach like other
OOP languages, or something like this that tries to merge them together. I
like the terseness of the last option but I worry that trying to use a
single curly body to do double-duty in that way will come back to haunt us.
Still, I think what you have here is a very lucid approach to that option.
Cheers!
- bob
On Tue, May 22, 2012 at 7:55 AM, Luke Hoban <lu...@microsoft.com> wrote:
> In the discussion of max/min classes at the March TC39 meeting, there was
> support for minimal class syntax, but a couple concerns with max/min
> classes in particular.
>
> One category of concern is the (intentional) bare-bones nature of max/min.
> In this case though, I think it has been demonstrated that additional
> concepts (class properties, privates, prototype properties, etc.) can be
> added to max/min later, if and when experience shows them to be needed.
>
> The other category of concern is that max/min decides the core syntactic
> use of the valuable 'class' reserved keyword in the language. Max/min
> chooses to use 'class' for a new kind of block with a nested constructor,
> instead of as direct extensions of the notion of constructor function.
>
> I've raised the class as constructor alternative approach before, and it's
> something that a few teams I've worked with inside Microsoft have
> advocated. Since a choice on approach for classes will decide the
> foundation upon which the class keyword is used in the language going
> forward, I did a writeup of the alternative syntactic approach at
> http://wiki.ecmascript.org/doku.php?id=strawman:minimal_classes_as_constructorsfor
> comparison.
>
> Here's one of the examples from the write-up:
>
> class SkinnedMesh(geometry, materials) extends THREE.Mesh(geometry,
> materials) {
>
> // properties on the instance object
> public identityMatrix = new THREE.Matrix4();
> public bones = [];
> public boneMatrices = [];
>
> // ... note, this is the constructor body, statements are allowed here
>
> // methods on the prototype object
> public update(camera) {
> // ...
> super.update();
> }
> }
>
> Classes as constructors aims to align more closely with existing
> 'function' syntax, augmenting with the ability to declaratively specify
> members of the class. Importantly though, methods (and accessors) defined
> in the class body are bound as prototype properties, not instance
> properties. This can lead to more succinct classes in many cases, and
> keeps the notion that a class is primarily a constructor function.
>
> Luke
>
>
> _______________________________________________
> 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
