>
> 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
