AWB alternative 2 - instance vars and secret methods

[allenwb]

Max-min classes 1.1. AWB alternative 2

An updated version of this proposal is below at #7 (comment)

Here is a proposal that is closer to the @zenparsing parsing original, but perhaps simpler. With this proposal, I don't necessarily see the need for a classes 1.2 follow-on

Basic Concepts

• This proposal adds the concept of secret class elements to ECMAScript class definitions. Secret class elements are only accessabe from within the body of a class definition.
• There are three kinds of secret class element, static initializer blocks, instance variable definitions, and secret method definitions.
• A class definition may contain at most one static initializer block it is automatically executed as the final step of class def evaluation
  • The static initializer block is a secret of the class definition, there is no way to invoke it from outside of the class definition
• A instance variable definition defines one or more secret variables that exist in each instance of a class.
  • An instance variable defnition within a class body looks like this:

  var x,y;  //each instance created by this class constructor will have these two instance variables

  • Within a class body, instance variables are accessed using the -> operator like this:

  this->x = 0;
  console.log(obj->y);

  • Instances variable names are lexically scoped and visible to everything contained in a class body.
  • Attempting to access an instance variable using -> produces a runtime ReferenceError if the object does not have the specific named instance variable defined by this class definition. In other words, A reference to an instance variable only works when the objectise a normally constructed instance of this class or one of its subclasses.
  • Instance variable definitions don't have initializers. Instance variables are usually initialized by the constructor. An uninitialized instance variable has the value undefined.
• A secret method definition is a concise method that can only be directly involked from inside the class body.
  • A secret method definition looks exactly like a concise method except its name is prefixed by ->
  • Here are some examples of secret method definitions

  ->foo() {return super.bar()}
  get ->x() {return this->_x}  //a secret accessor method
  set ->x(v) {this->_x = v}

  • Secret method names are lexically scoped and visible to everything contained in a class body.
  • Within a class body, secret methods are invoked using the -> operator like this:

  this->foo();
  obj->x = 5;   //invokes a secret set accessor method
  this->foo.bind(this);  //access the function value of a secret method

  • Secret methods can be accessed/invoked with any object supplied to the left of the ->. It is up to the code of the method body whether or not a runtime error will occur if the this value is not an instance of the containing class or one of its subclasses. Access to instance variables that don't exist for the this value would, of course, throw.
• It is an early error if the name occuring to the right of a -> operator is not the lexically visible name of a secret method.
• No reflection on instance variables, instance variable names, secret methods, or secret method names
• Lexically scoped instance variable and secret method declarations introduce new names into a parallel scope (does not shadow non-secret names)

Example

class Point {
   var x;    //or:  var x, y;
   var y;  
   
   ->brandcheck() {
      try {this->x} catch {return false};
      return true;
   }
       
   get x() {return this->x} //normal accessor properties
   get y() {return this->y}
   
   add(another) {  //a normal method property
      if (another.brandcheck()) 
        return new Point(this->x+another->x, this->y+another->y);
      else 
        return new Point(this->x+another.x, this->y+another.y);
   }
   
   constructor (x,y) {
      this->x = x;
      this->y = y;
   }
}

Technical Notes and Rationale

• var is repurposed to declare instance variables because its name is suggestive of "instance VARiable". Note that several early ES class proposals including the original ES4 proposals used var for this purpose.
• Secret names (instance variables and secret methods) exit in the same namespace so an instance variable may not have the same name as a secret method.
• The kind of thing a secret name is bound to is based upon its declration. -> may statically determines from the supplied name whether it is accessing an instance variable, a secret accessor method, or invoking a secret method.
• Any concise method form may be used to define a secret method. It's the -> prefix to the name that makes it a secret method.
• Secret methods don't have any special semantics for their bodies. The Home object of a secret method is the prototype object defined by the class.
• There is no particular reason why we couldn't have static instance variables and static secret method definitions. But it is simplier to not have to explain how they differ from the non-static forms.
• Instance variable declrations do not have initializers to simplify things. Without them, we don't have to define their evaluaiton order or the scoping of the initializer expressions. People are already used to using constructors to initialize instance state.
• It is an early error to assign to a secret method reference (unless it is an accessor method)
• Because secret methods are statically resolvable and immutable, it is easy for an implementation to statically in-line them. No flow analysis or dynamic specialization required.
• The var declarations of a class collective and statically defined the "shape` of the secret instance state introduced by that class definition. Subclass can add additional secret state "shapes" but overall it is a step closer to objects with a fixed shape determined at class definition time and should also make it easier to lift the internal checks needed on instance var accesses.

[zenparsing]

I need more time to think about it but with a little bikeshedding this could be something...

Speaking of which, the -> prefix might be a little too sigily for some tastes. I wonder if we could come up with a keyword that would fit just as well? Obviously, not private or protected. Maybe internal?

Could we get away with a keyword without breaking the user's intuition regarding ->?

[allenwb]

Well I really like using the same symbol sequence for both the actual selection operator and the sigil that distinguishes a property based concise method from a "secret" concise method. It really ties the two together. The problem with a keyword is that the actual word you choose can carry too much implied meaning and clutter. And, how much push back to we get from the generator *.

But, if we really wanted a keyword why not "secret" I also considered "hidden" as terminology before I went with "secret" in the write-up. It might actually be better.

And, of course we could try .. instead of ->. Initially I liked foo..bar better because is was so similar to foo.bar. But -> grew on me. Mess chance of a type stutter and the distinction between the two operator is big enough that it may be worth a bit more emphasis.

You could try some examples using just those variations. I did a bunch of that various class forms in the early ES6 days. In the end, there just wasn't that much meaningful different between various forms.

[zenparsing]

I've updated the examples to use this syntax, with hidden as the placement modifier.

I think a -> prefix might get a little funky once we consider some other combinations we'll have to deal with:

class C {
  ->*foo() {}
  ->async foo() {}
  ->async *foo() {}
}

I thought "secret" might be a little too strong (or James Bond-esque), but "hidden" seems to provide the right connotation.

Since hidden methods can be called with any object as the receiver, it appears that they are completely sufficient for "static private":

class C {
  hidden factoryA() {
    return new this('a');
  }
  hidden factoryB() {
    return new this('b');
  }
  static factory(kind) {
    return kind === 'A' ? this->factoryA() : this->factoryB();
  }
}

Do you agree? This seems at the same time both wonderful and surprising to me!

[zenparsing]

One aspect that might stand out to people is the lack of initializer expressions on instance variables. I agree that we don't need them and the design is simpler without them. Another benefit of leaving initializers out is that the installation of instance variables is atomic: an instance either has all of them (defined by a single class) or none of them. I've desperately wanted that ever since starting to work on private state.

Even if we add initializer expressions in a future update, I think that we ought to retain that property.

[allenwb]

what I had in mind was more along these lines:

class C {
  *->foo() {}
  async ->foo() {}
  async *->foo() {}
}

the -> always directly precedes the name.

I'm beginning to like the "hidden" terminally more than "secret", regardless of whether we use it as a keyword or just as terminology.

The main issue WRT "static" hidden methods is the Home object binding if they use super. In principle there is no reason that we could have static hidden methods which would have a correct home object binding. The only reason I left it out was to simply the overall proposal. But consistency (any concise method form can be hidden) is also a form of simplification.

But, for me, having static hidden methods is a point in favor of the sigil instead of the keyword:

static ->factoryB() { } seems more concise then static hidden factoryB() {} or is it hidden static factoryb() {}. Gets even worse with static hidden async *factoryB() {}.

[allenwb]

Yes, I prefer to leave the initializers out and require the declarations (no creation of instance vars by assignment)

I think we need to be careful of feature-creep. One of the strongest arguments agains the current set of proposed class extensions is the overall complexity when you include everything.

[zenparsing]

static hidden factoryB() {} or is it hidden static factoryb() {}

If we go the keyword route, we could allow either I think (similar to the method modifiers in C#):

ClassElement:
  ClassElementModifier* MethodDefinition ;

ClassElementModifier:
  'static'
  'hidden'

Since static results in a different Home object, then I think we'll need to either:

1. Add support for hidden static
2. Make hidden methods not have a Home at all

Option 2 sounds somewhat nice to me in an abstract way, since these methods are kind of "homeless": they aren't actually attached to any objects. What would be the disadvantage of not having a Home (and thereby disallowing super)? I suppose that it could make it more difficult to transparently refactor normal methods that contain super references.

On the other hand, option 1 will probably be more intuitive to users.

[allenwb]

I'd go with option 1. I like the simplicity of being able to say any concise methods (that includes static methods) can be turned into a hidden method, and it doesn't change the behavior of the method.

For people who don't use super it won't technically matter but it's still natural for them to conceptually distinguish methods used to define the class (ie, constructor object) behavior and methods used to define instance behavior. And people who do use super and write static methods won't be surprised if things break if they invoke such a static method with an instance object. Basically, it feels simpler to have static hidden method then it would be to exclude them.

Allowing arbitrary ordering of class modifiers doesn't help the simplicity story very much. Programmers still have to pick an ordering and if they settle on using a specific ordering and they suffer some uncomforted each time they read code that uses a different order. And it certainly makes the specification more complex because it has to deal with the possibility of multiple occurrences of a modifier.

I still think we should lead with the name sigil and save the hidden keyword as a fallback position.

[allenwb]

Max-min classes 1.1. AWB alternative 2a

This is the same basic proposal at that at the head of this issue thread, but with terminology and other updates based upon the above discussion.

Here is a proposal that is closer to the @zenparsing parsing original, but perhaps simpler. With this proposal, I don't necessarily see the need for a classes 1.2 follow-on

The starting point for this proposal are ECMAScript class definitions as defined in the ECMAScript 2018 Language Specification. No, other proposed extensions are assumed or required.

Basic Concepts

• This proposal adds the concept of hidden class elements to ECMAScript class definitions. Hidden class elements are only accessible from within the body of a class definition.
• There are three kinds of hidden class elements, static initializer blocks, instance variable definitions, and hidden method definitions.
• A class definition may contain at most one static initializer block it is automatically executed as the final step of class def evaluation
  • The static initializer block is a hidden part of the class definition, there is no way to invoke it from outside of the class definition
• Instance variable definitions and hidden method definition define variables and methods that have lexically scoped hidden names.
  • Hidden names are accessed similarly to properties but use -> instead of . as the referencing operator.
• A instance variable definition defines one or more hidden variables that exist as part of the state of each instance of a class.
  • An instance variable defnition within a class body looks like this:

  var x,y;  //each instance created by this class constructor will have these two instance variables

  • Within a class body, instance variables are accessed using the -> operator like this:

  this->x = 0;
  console.log(obj->y);

  • Instances variable names are lexically scoped and visible to everything (including nested functions and class definitions) contained in a class body.
  • Attempting to access an instance variable using -> produces a runtime ReferenceError if the left operand is not an object with the specific named instance variable defined by this class definition. In other words, A reference to an instance variable only works when the object is a normally constructed instance of this class or one of its subclasses.
  • Instance variable definitions don't have initializers. Instance variables are usually initialized by the constructor. An uninitialized instance variable has the value undefined.
• A hidden method definition is a concise method that can only be directly invoked from inside the class body.
  • A hidden method definition looks exactly like a concise method except its name is prefixed by ->
  • A hidden method definition may be prefixed by the static keyword.
  • Here are some examples of hidden method definitions

  ->foo() {return super.bar()}
  get ->x() {return this->_x}  //a hidden accessor method
  set ->x(v) {this->_x = v}
  static ->from(itr) {return super.from(itr)}

  • Hidden method names are lexically scoped and visible to everything contained in a class body.
  • Within a class body, hidden methods are invoked using the -> operator like this:

  this->foo();
  obj->x = 5;   //invokes a hidden set accessor method
  this->foo.bind(this);  //access the function value of a hidden method

  • Hidden methods can be accessed/invoked with any object supplied to the left of the ->. It is up to the code of the method body whether or not a runtime error will occur if the this value is not an instance of the containing class or one of its subclasses. Access to instance variables that don't exist for the this value would, of course, throw.
• It is an early error if the name occurring to the right of a -> operator is not the lexically visible name of a hidden method or instance variable.
• No reflection on instance variables, instance variable names, hidden methods, or hidden method names
• Lexically scoped instance variable and hidden method declarations introduce new names into a parallel scope (does not shadow non-hidden names)

Example

class Point {
   var x;    //or:  var x, y;
   var y;  
   
   ->brandcheck() {
      try {this->x} catch {return false};
      return true;
   }
       
   get x() {return this->x} //normal accessor properties
   get y() {return this->y}
   
   add(another) {  //a normal method property
      if (another.brandcheck()) 
        return new Point(this->x+another->x, this->y+another->y);
      else 
        return new Point(this->x+another.x, this->y+another.y);
   }
   
   constructor (x,y) {
      this->x = x;
      this->y = y;
   }
}

Technical Notes and Rationale

• This proposal avoids using keywords or syntax that are already used by widely deployed JavaScript transpiler based extensions or dialects such as TypeScript. Transpilers can continue to support those extensions even when the target language includes features from this proposal.
• var is repurposed to declare instance variables because its name is suggestive of "instance VARiable". Note that several early ES class proposals including the original ES4 circa 2000 proposals used var for this purpose.
• Hidden names (instance variables and hidden methods) all exit in the same namespace so an instance variable may not have the same name as a hidden method.
• The kind of thing a hidden name is bound to is based upon its declaration. the -> operator may statically determines from the supplied name whether it is accessing an instance variable, a hidden accessor method, or referencing a hidden method object.
• Any concise method form may be used to define a hidden method. It's the -> prefix to the name that makes it a hidden method definition.
• Hidden methods don't have any special semantics for their bodies. The Home object of a hidden method is the prototype object defined by the class unless the hidden method definition has the static modifier. In the static case, the Home object is the class' constructor function.
• There is no particular reason why we couldn't have static instance variables But some people find the semantics of static instance variables unintuitive so it is simpler to not have to explain how they differ from the non-static instance variables.
• Instance variable declrations do not have initializers to simplify things. Without them, we don't have to define their evaluaiton order or the scoping of the initializer expressions. People are already used to using constructors to initialize instance state.
• It is an early error to assign to a hidden method reference (unless it is statically resolves to an accessor method)
• Because hidden methods are statically resolvable and immutable, it is easy for an implementation to statically in-line them. No flow analysis or dynamic specialization required.
• The var declarations of a class collectively and statically defined the "shape` of the hidden instance state introduced by that class definition. Subclass can add additional hidden state "shapes" but overall this is a step closer to objects with a fixed shape hidden shape determined at class definition time and should also make it easier to lift the internal checks needed on instance var accesses.

[zenparsing]

This is looking great - thanks!

I must admit a strong preference for the keyword here. It seems to just slide right in to the current class aesthetics. It "sings" to me. If we do end up going with "hidden", and we want a specific order, then I'm leaning towards "static hidden".

Bikeshedding aside, the only other issue I have has to do with the interaction between normal lexical scope and instance var names. Consider:

var x = 1;
class C {
  var x;
  constructor() {
    console.log(x);
  }
}
new C(); // Logs "1"

Similarly:

var x = 1;
class C {
  var x;
  constructor() {
    console.log(eval("x"));
  }
}
new C(); // Logs "1"

This seems surprising to me. Do you think we can use early errors or uninitialized bindings in the class body scope (or both!) to eliminate such cases?

[allenwb]

Well, it would be no different if you had written:

let x = 1;   // <-- changed var to let
class C {
  var x;
  constructor() {
    console.log(x);
  }
}
new C(); // Logs "1"

or

class C {
  var x;
  constructor(x) { // <----- added parameter
    console.log(x);
  }
}
new C(1); // Logs "1"

These example helps illustrate that there are two key things that people who use class definitions have to learn:

1. var as a class body element means something completely different form var in a statement list. (and it would probably be a good idea to stop using statement list var declarations)
2. An identifier only binds to a hidden name if it immediately follows ->. In other contexts normal lexical or property binding is used for the identifier.

I don't believe the eval changes anything as strict mode direct evals evaluate in a new nested lexical scope. The more interesting questions is whether the following is valid or is it an early error?

var x = 1;
class C {
  var x;
  constructor() {
    console.log(eval("this->x"));
  }
}
new C(); // Logs "1"

Should this be legal? Probably. Eval has special early error rules for new.target, SuperProperty and SuperCall that ensures that they only occur in evals that are within an appropriate kind of method. Interestingly, it is less clearly that eval("continue;") etc. are adequately specified.

Regarding, hidden vs -> name prefix in concise methods. I think we need to get a bigger sample of opinions as it seems mostly like an esthetics based preference.

[zenparsing]

var as a class body element means something completely different form var in a statement list. (and it would probably be a good idea to stop using statement list var declarations)

Yes, this is the hangup. When I let go of my vestigial concept of var I can see it from your point of view entirely. The question, I think, is whether we can convince others to let go of their vestigial concept of var as well.

On the other hand, I'm not 100% convinced yet that we can't have it both ways. I think that given the history of var and the experience of other languages, unqualified access to instance vars can be pretty intuitive and some developers will appreciate the brevity.

[allenwb]

We could have hidden x; instead of var x; but it quickly leads to requests for unhidden x; or even just x; and with ASI x

The nice thing about the instance variable concept it is explicitly labeling x as a specific kind of thing rather then just emphasizing it's visibility while leaving what kind of thing x is implicit.

Even if we could make unqualified access to instance variables work in JS (and I very dubious) it's still a complication. To have any change with this proposal I think we have to focus on simplicity.

[zenparsing]

That's exactly my worry with using hidden for instance variables themselves: it's a slippery slope.

Also, from an aesthetic standpoint, I like the fact that with the current proposal it is easy to simply glance at a class definition and understand the internal storage requirements for instances, independent of any surface API or internal code organization.