> > 1. More syntax means larger language surface, which adds complexity > more things to remember / learn. More things to consider in ES.next.next >
Yup, languages almost always tend to get bigger over time since it's really hard to remove features. For me, the goal isn't to make the language as *small* as possible, it's to make it as *powerful* as possible where I define "power" as "expressiveness / size". If a new feature adds a lot of expressiveness (and I do believe our class proposal does), then to me that's a win. > 2. I OOP in JS is already confusing for people coming from other languages, > this proposal will make it even more confusing. > It is very confusing. My belief is that it's confusing mainly because you're forced to dig into the underlying machinery to do OOP in JS instead of having a declarative form that reflects your intent. Say you're thinking "I want to define a kind of Person object where each person has a name and they have a method where they say their name." In JS, you have to then know the underlying prototype machinery required to achieve that intent: function Person(name) { // Why does a function define a kind of thing? this.name; } Person.prototype.say = function() { // Where did this magic prototype object come from? log(this.name); // How is "this" bound to an instance of a person here? } It's good to have access to this low-level stuff when you need it, but forcing users to go through that all the time is I think where the confusion comes from. It's a bit like if you had to open the hood and reach into the engine every time you needed to change gears. It *works*, but it's not what I'd call *usable*. A good class syntax can essentially be a nice simple gearshift level that users can access from the comfort of their seat: class Person { constructor(name) { this.name = name; } say() { log(this.name); } } >From my perspective main problem today is verbosity, which can be > fixed without introducing new syntax. Also while I named some disadvantages, > I can't really see any advantages of dedicated syntax, there for I think > it's better to avoid adding more syntax changes. > I definitely like the idea of minimizing new syntax and taking advantage of JS's existing expressiveness. But there are some things that dedicated syntax can give you. With current class patterns in JS, the language itself has no idea *textually* that you're making a class. That limits the terseness it can provide to you. For example, the current proposal (and a little extra sugar in Traceur's flavor of it) let you do this: class FramedButton extends Button { paint() { drawFrame(class.thickness); super.paint(); // Call base class version. } static const thickness = 3; } Here, super desugars to FramedButton.prototype.paint.call(this); This is terse, less error-prone, and avoids mentioning the base class by name which makes it easier to refactor hierarchies. Likewise, class.thickness desugars to FramedButton.thickness. This is again terse and friendlier towards refactoring. The reason we can make that work is because where those super and class.calls appear, we can *textually* tell that we're inside a class definition so we know what to desugar to. Existing class patterns that work imperatively don't have that luxury. - bob
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss