>> 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; }
>> }
Right - this is the concern that others raised on a parallel branch of the
discussion. Although I see the concern, I think this is not necessarily a
fatal concern, and there are options that could help here raised on the other
thread.
>> 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.
While having a new kind of body for classes does have some benefits, it also
comes at the cost of making classes heavier in all cases. I think this is the
core aspect of the tradeoff between the two syntactic approaches.
> 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.
In the approach of treating a class as a constructor, class properties can be
added in the future just as "static foo() {}". I don't think this needs a
separate block, assuming you buy into the first question raised about
expectations of scopes.
Luke
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
