I noted some open issues on "Classes with Trait Composition"

[David Herman]

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