I wrote up some thoughts on the proposal to replace the current Stage 3 class proposals with a clean slate design: https://gist.github.com/wycats/b1c96c67074396a239abd60f55087adc …
Should be a major topic of this week's TC39 meeting. Very interested in feedback.
Lots of links if you need context 
What do you think about `var` as the way to declare private instance variables?
-
-
It's less offensive than # on the surface, but I wonder if it might be confusing since it doesn't behave like folks have learned `var` does (access and assignment without `this->`). If `hidden concatIds(){}`, why not also `hidden ids;` for consistency?
-
-
I would object to `this.
@foo` also. I think enough languages use # for comments that it doesn't read naturally. I imagine a language that used // as an operator would have the same trouble. But `this.#something` is the worst part for me -
Can you imagine getting used to it as analogous to leading `_`?
-
-
With the shorthand as the default usage, I think it’d be way more palatable. Without dynamic/variable access or access from the exterior, I’m having trouble imagining when the ivar_get equivalent would be needed
-
Ohh interesting. I hadn’t understood that privacy functioned like that. Was imagining “instance private” not “same constructor/class private” Can instances assign to each other’s privates? Is it a parser nightmare/impossibility to do other#x without the dot?
- 3 more replies
New conversation -
-
-
I would rather expect `let` as it is the JS block-scope variable keyword.
-
But this is not like a var or let. The proposal uses var to remind you of "instance VARiable"
-
Got that but still would perceive the let block-scope-ness as being a better hint on the variable to be private instance var.
End of conversation
New conversation -
-
-
Prefer also not to have the -> syntax. Don't need the setters to know if something is private or not. There is such great prior art from c# here which really fits nicely
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Honestly not great. Var already has dirty smells around it which gave us let. Now we are reusing it for something else
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I sort of warmed up to `var` quickly, but I can see it being objected to since it's not actually accessible via lexical scope as one might expect. What if there were just a new token (private? self? local?) to replace var, but everything else remains the same?
-
Hm, specifically, I think a very good reason *not* to add to confusion by making it "var" is that many developers already get "scope" and "context" (this) confused. I often see this in interviews. "var" implies scope when in fact you're adding to the instance's context.
-
I guess you're not technically adding in to the context in the same capacity you would with `obj.x = y`, since it's only accessible by methods defined within the class curly braces, but it's still not quite the same thing as scope.
-
A particularly confusing comparison would be class definitions which declare private variables using `var` contained inside a closure. It would be hard to explain to a new developer why they can access that `var` via scope in that case, but not in the Clean Slate case.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.