[Harmony classes] method lexical scope for InstancePropertyDefinitions, PrototypePropertyDefinitions?

Brendan Eich brendan at mozilla.com
Tue Jun 14 15:27:55 PDT 2011


On Jun 14, 2011, at 2:45 PM, Gavin Barraclough wrote:

> For example, given the following class:
> 
> class Box {
>    Box(x, y, z, density) {
>        public x = x;
>        public y = y;
>        public z = z;
>        private density = density;
>    }
> 
>    public volume()
>    {
>        return this.x * this.y * this.z;
>    }
> 
>    public weight()
>    {
>        return this.volume() * private(this).density;

Remember, private(this) is intentionally-burn-notice straw at this point.


>    }
> }
> 
> If instance properties are in scope the methods volume and weight could be written as:
> 
>    public volume()
>    {
>        return x * y * z;

This works for the public instance properties, but IIRC some folks object that it is too easy to make mistakes vs. formal parameters of the same name.


>    }
> 
>    public weight()
>    {
>        return this.volume() * density;
>    }

Here's the killer. density is private. Yes, in this case there can be no other density, but the Point equals method that needs to use p at x and p at y or private(p).x and private(p).y to compare to the other (argument) point p must have new notation for referring to the private instance variable of the other maybe-instance.

Same if you had a compareDensity(otherBox) method here.

Given this, putting the private in scope is helpful for self-references but not for other-refs, and it is a bit misleading.


> Similarly, if prototype property definitions were brought into scope we could omit the 'this.' on the call to volume:
> 
>    public weight()
>    {
>        return volume() * density;
>    }

Object != scope. We do not want mutable objects on the scope chain. We don't want any objects on the scope chain, really. This goes for modules too, they are closed for a reason.


> Might this go some way towards resolving the verbosity of the use of private(this), currently listed as an open issue on the classes proposal, since in many methods these could be omitted?

Not in the case of private(other). Without static type information for the parameter to equals and methods like it, we need a separate notation for accessing privates.

/be


More information about the es-discuss mailing list