I noted some open issues on "Classes with Trait Composition"
Bob Nystrom
rnystrom at google.com
Thu May 19 13:08:47 PDT 2011
On Thu, May 19, 2011 at 11:47 AM, Brendan Eich <brendan at mozilla.com> wrote:
> Here's another question: how many property initializations could be done
> straight from the parameter of the same name?
>
Of the 88 fields I looked at, 10 were straight copies of a constructor
argument. Another 4 are copies with an "if undefined then use this default
instead" check. That may be biased a bit low since most of the code I looked
at is UI widget-like stuff. Code that's more data-model oriented would
probably have more cases where a class is just wrapping a bunch of
arguments.
Apart from the desire to declare per-instance property names, do we really
> need default values if the constructor author could write default parameter
> values?
>
> class Point {
> constructor(x = 0, y = 0) {
> this.x = x;
> this.y = y;
> }
> ...
> }
>
That covers a different (though useful!) case. This would be helpful for the
4 cases above where a field is initialized to a constructor argument if
given, or to a default value if not. For the 34 other cases, those fields
don't come from the constructor arguments at all.
> class Point {
> constructor(this.x = 0, this.y = 0) {
> }
> ...
> }
>
Yeah, that's in the document the proposal is linking to now (
https://docs.google.com/document/d/1gOFRSBOKtB8VjXC5LRhhNiGi1n1QQ6z1O6LyxjrOB3g/edit?hl=en_US).
I'd like to roll that into the proposal as an optional refinement. I really
really like this.
> The objection here is that @ is coveted, for private names or decorators.
>
FWIW, my vote would be to keep that for decorators/annotations.
> Perhaps we could use leading dot in formal parameter names to mean this.:
>
> class Point {
> constructor(.x = 0, .y = 0);
> ...
> }
>
> Comments welcome!
>
That's delightful!
- bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110519/4baa23f4/attachment.html>
More information about the es-discuss
mailing list