How to critique this proposal

[allenwb]

When reading and raising issues about the Max-Min Classes 1.1 proposal it is important to understand how it relates to the current set of class feature proposal that are at various states in the TC39 process pipeline.

This proposal is a response to the overall complexity that would be introduced into the language by the full collection of current and contemplated proposals. Basically, we don't think that the JS complexity budget for the near future is big enough to invest so much of it into class extensions. JavaScript has generally followed a minimalist design style. From that perspective, the contributors of this proposals are primarily concerned about the amount of complexity that the existing proposal would inject into the language. The complexity concern has also been raised by a number of community members.

This proposal is not a point-by-point attack of any feature of any of the current proposals. There are many good ideas in the existing proposals. Some of them we've borrowed. Instead, this proposal is an attempt to fight back against overall complexity. We are not trying to "fix" or improve other any existing proposal. It is an experiment to see where we might end up if we start with a clean slate and took a minimalist approach to adding some pretty essential functionality that is not in ES6 class definitions. We want to see where we get if following that same Max-Min methodology that enabled the introduction of class definition syntax into ES6.

This proposal is a carefully balanced set of functionality that attempts to include just enough and not too much new capability and associated new complexity. The best way to critique this proposal or understand the rationale for our decisions is to focus on the actual proposal rather than trying to do a feature-by-features bake-off against other proposals. For example, rather than asking "why did you leave out public fields?" ask "Why didn't you include a mechanism for declaring instance own properties?"

We fully expect to have to explain difference between various features of this proposal and other proposals. Just remember, that sort of point-by-point comparison is not the design methodology we have followed and may not give you the best understanding of this proposal. Try to understand it as a whole before you start the feature point comparison.

[bakkot]

Instead, this proposal is an attempt to fight back against overall complexity.

I definitely feel the complexity budget squeeze as the language continues growing. But... I guess I really don't share the impression that this proposal uses less of it than the existing one. It adds four new and diverse syntactical forms, one of which overloads an existing one with radically different semantics: var x, hidden foo(){} this->x, and static {}. And it fails to provide for what I think is the overwhelming majority use case, which is initializing public instance & static fields. It feels like spending more and getting less.

I agree that the important thing is to consider proposals holistically, with a particular emphasis on overall complexity. I am just confused by the implication that this proposal is less complex that the current one. To me it feels far more so.

[zenparsing]

I guess I really don't share the impression that this proposal uses less of it than the existing one.

As @allenwb states, the comparison should not be to any single proposal in isolation, but to the full set of class features that are either in some form of development or have been deferred to future proposals. That is a large list, with noticeable unresolved problems. We see our alternative as a small, closed, self-sufficient set of essential functionality.

Of course it's not perfect (yet?), but that's not the point. The point is to see if we can create an alternative that is complete (and therefore represents less design risk), while avoiding some of the troubles that the current proposals find themselves in.

[ljharb]

One conflict here is that some of the use cases this "minimal" proposal doesn't address, are indeed essential. The complexity that the current fields proposals add tends to be deemed "very much worth it" by those who need these use cases.

If a less complex proposal can address them, then great! However, if not, then it's not actually a better proposal - it's just a simpler one, which isn't inherently better in and of itself, despite the value of minimizing complexity.

[allenwb]

@ljharb

some of the use cases this "minimal" proposal doesn't address, are indeed essential.

I guess it depends upon your definition of "essential". The definition I use is provided in #11

But from a Max-min design approach, the meaning of essential is fairly straight forward. If all of the stake holders in the design agree that something is essential, then it is essential. If there is disagreement as to whether or not some feature or capability is essential, then for the purposes of the Max-min design it can't be considered essential.

As a starting point on what is essential, I this we have significant consensus that some mechanism that provides securely encapsulated per instance state is essential.

[ljharb]

Max-min motivated the ES2015 design, and while that may very well have been the right decision, I'm not sure that was in fact considered "successful" nor that max-min is automatically the right approach to take now that we have the post-ES6 process.

[hax]

This proposal is great!

It avoid the main syntax issues in current proposals:

1. No #priv which most programmers hate. (Yes, they hate it.)
2. No new ASI hazard. (by reuse var keyword)

It also make the internal slot (instance variable) concept much much clear by introduce -> diff from . or [].

I agree public property initialization is good to have, but not must to have in current stage. We could leave it, check how TypeScript users use the features here proposed and property initialization they supported together, then decide whether or how to introduce public property initialization in the future.

I LOVE this proposal! Thank you @zenparsing and @allenwb to bring this to us!

[littledan]

Note that it's the combination of reusing the var keyword and not having any initializers that make this proposal eliminate ASI hazards.

[hax]

@littledan I think even having initializers it will make much less new ASI hazards than current proposals.

class A {
  var x = 0
  *gen() {}  // syntax error
  var y = 1
  [computed]() {} // syntax error, and it's not a new ASI hazard for semicolon-less coding style
}

All other weird cases are just gone.

[bakkot]

@zenparsing,

but to the full set of class features that are either in some form of development or have been deferred to future proposals. That is a large list, with noticeable unresolved problems

This confuses me a bit; can you be more explicit about what you're referring to?

[hax]

@bakkot

one of which overloads an existing one with radically different semantics: var x, hidden foo(){} this->x, and static {}.

• var x: I think this syntax is very easy to understand, the old var is for function local variables, and this is for class "local" variables.
• this->x: At least much better than #x
• static {}: Easy to understand for Java/C# programmers. (Though C# use a little different syntax.) It seems current proposals do not have corresponding feature. As the examples showed, I see it's a useful feature, but as I understand it's not the core feature of this proposal and can be postponed, I can live without it.
• hidden foo(){}: I wish it could be private foo() {}, but it rely on TypeScript team's decision of how to incorporate their private and js native private/hidden. So I'm fine with hidden, we already introduce keywords like yield/async/await, so it's not a big deal. Again, at least much better than #foo() {} for most programmers.

[bakkot]

@hax:

var x: I think this syntax is very easy to understand, the old var is for function local variables, and this is for class "local" variables.

It's not a class local variable, since a function which closes over it will see different values depending on how the function is invoked, which breaks a fundamental contract of variables in JavaScript. It's not a variable at all, in any sense. Short of eval, there's no place in the language where you can summon a new variable into being without creating a new function. It's a value associated with an object. I get why it's confusing to call it a property, but I think it's more confusing to think of it as a variable.

[etc]

I'm not saying any of these are necessarily bad, except the first. I'm just saying they collectively add a huge amount of complexity to the language. I stand by that claim.

[allenwb]

I'm not saying any of these are necessarily bad, except the first. I'm just saying they collectively add a huge amount of complexity to the language. I stand by that claim.

Of course this proposal adds complexity to the language. If it didn't add some complexity it would be adding any new expressibility to the language. What it tries to avoid in adding inessential complexity.

You aren't arguing that this proposal adds more complexity then then union of all the class extensions proposal that are already in the TC39 pipeline, are you?

[bakkot]

@allenwb,

You aren't arguing that this proposal adds more complexity then then union of all the class extensions proposal that are already in the TC39 pipeline, are you?

I can't answer this without knowing which things we're considering to be class extensions proposals. The class fields proposal, sure, but... Callable constructors? Decorators? Mixins? A future shorthand for private field access? I don't see how this proposal would rule any of those out, for example, and commentary elsewhere suggests it's not intended to. But as such I don't understand why we'd be interested in comparing the complexity cost of "this proposal" vs "the current class fields proposal, plus callable constructors, plus decorators, plus mixins, plus shorthand".

I do claim it adds more complexity that the current class fields proposal. I personally would be more than content to get just that proposal and no others, so from a max-min perspective, it seems like that proposal would be a strict improvement over this one.