On Mon, Jul 18, 2011 at 10:32 AM, Allen Wirfs-Brock <al...@wirfs-brock.com>
wrote:
> This is a nice declarative way to describe the per instance state but it
turns out it doesn't generalize very well to multiple levels of inheritance.
This is an important point. I think the reason most OOP languages make a
distinction between object construction and initialization is because in the
presence of inheritance, you need 1 construction, but N initializations
where N is the depth of your inheritance chain. If you try to construct and
initialize in one step, it's hard to do that (as your proposal addresses).
> A similar issue exists for the proposed class declarations. That proposal
includes the concept of "static" (a lot of us don't like that the term
"static" in this context) property declaration:
Yeah, I don't think anyone is crazy about that keyword, but it's:
1. Reserved already.
2. Familiar from other languages and it works about the same here as it does
in those.
I liked "class" instead, but the worry about nested classes was enough to
talk me out of it.
We have a challenge with JS keywords:
1. We want to re-use keywords from other languages to make JS familiar and
to use what's already in the programmer's head. If some JS construct looks
and acts similar to a construct in other popular languages, using the same
word for it is like instant knowledge.
2. We want to emphasize JS's unique features. JS is not Java (or C++, or C#,
or Smalltalk, or Ruby) and we run the risk of leading users down a false
path if we make JS look superficially too much like them. There's also a
strong cultural bias where JS = light, terse, expressive, fun and Java =
verbose, rigid, work. Borrowing keywords from Java makes people worry that
there's going to be a JavaScript khaki dress code. Personally, I think
that's much ado about nothing, but I can understand why people would worry
that the suits are going to show up and crash the party.
> Static properties are really just own properties of the constructor
object. While sometimes useful, they occur relatively infrequently yet they
require a additional declaration form within class bodies.
I just did some quick hunting through a few classes in the Closure library.
Instance methods are definitely the most common kind of member there, but
static methods were used in every type I looked at. For example,
goog.ui.Component has a static mutable field, three "constants" which are
properties on the constructor, and a couple of static methods.
goog.ui.Tooltip has five members that would use "static" in the class
proposal.
> This complicates the conceptual model of a class declaration by allowing
intermingling of constructor and prototype property declaration.
There can also be confusion between what goes on the prototype and what goes
on the new instance.
> This also increase the potential for confusion about the meaning of "this"
(and "super") within such static property declarations.
Good point. From a conceptual simplicity argument, I like the idea of having
different curly blocks for "stuff on the ctor" and "stuff on the proto".
Pragmatically, though, C++, Java, and C# all mix instance and non-instance
members together and people seem to get by without too much trouble.
Looking at your example:
class Point {
private __validate(x,y) { return typeof x == 'number' && typeof y =
'number'};
constructor(x,y) {
if (!this.__validate(x,y)) throw "invalid";
return this <& {
private __x: x,
private __y: y
};
}
} <& {
get origin() { new this(0,0); }
};
A few things stand out for me:
1. Personal preference, but it's pretty punctuation heavy.
2. It seems strange that the instance methods are in the class block, and
the methods on the class itself aren't. That feels backwards.
3. Unless I've had it explained to me, there's no way I could figure out
what that code means even if I'm an expert in other programming languages.
- bob
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
