I noted some open issues on "Classes with Trait Composition"
David Herman
dherman at mozilla.com
Thu May 19 07:05:09 PDT 2011
Yes, we've talked about this. One of the issues I don't know how to resolve is if we want to allow the specification of class properties aka statics, then those need *not* to be in the scope of the constructor arguments, which ends up with very strange scoping behavior:
var x = "outer"
class C(x) {
static foo = x // "outer" -- whoa!
}
I'm not 100% up on the current thinking of the group that's been working on classes, and whether they are including statics in the design, but I think they are.
Dave
On May 19, 2011, at 5:36 AM, Andreas Rossberg wrote:
> My apologies if this has been discussed to death before -- well,
> actually, I'd be surprised if it hasn't (pointers would be welcome).
>
> I think it is worth noting that the baroque notation for defining
> constructors that we see in the C++ / Java / C# world primarily is an
> artefact of the desire to allow multiple constructors with overloading
> in those languages. We don't have that issue in JS, so I wonder why we
> cannot go for something more elegant? There is precedent in other
> OOPLs (off the top of my head, e.g. Scala and OCaml) for putting the
> constructor arguments on the class head directly, and executing the
> class body like a block when the constructor is invoked. AFAICS:
>
> -- This approach is significantly slimmer (and, I'd argue, more
> readable) than the discussed alternatives, without needing any
> keywords:
>
> class Point(x0, y0) {
> public x = x0
> public y = y0
> }
>
> -- It naturally allows what Bob was suggesting:
>
> class Point { // no argument list would be shorthand for (), just
> like when invoking new
> public x = 0
> public y = 0
> }
>
> -- It avoids additional hoops with initializing const attributes:
>
> class ImmutablePoint(x0, y0) {
> const x = x0 // just like elsewhere
> const y = y0
> }
>
> -- The constructor arguments naturally are in the scope of the entire
> object, so often you do not even need to introduce explicit (private)
> fields to store them:
>
> class Point(x, y) {
> public function abs() { return Math.sqrt(x*x, y*y) }
> }
>
> /Andreas
>
>
> On 19 May 2011 03:31, Mark S. Miller <erights at google.com> wrote:
>>
>>
>> On Wed, May 18, 2011 at 6:29 PM, Brendan Eich <brendan at mozilla.com> wrote:
>>>
>>> On May 18, 2011, at 5:57 PM, Bob Nystrom wrote:
>>>
>>> class Point {
>>> public x = 0, y = 0;
>>> }
>>> let p = new Point();
>>> p.x; // 0
>>>
>>> This is pretty rare, in my experience. A hard case? If the constructor
>>> does set x and y from parameters, then you have double-initialization. If
>>> some properties are non-writable, you can't do this. YAGNI?
>>
>> +1. If you're gonna initialize them somewhere, why not always do so in the
>> constructor and avoid special cases?
>>
>>>
>>> /be
>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
More information about the es-discuss
mailing list