On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote:
> On Mon, Jul 18, 2011 at 10:32 AM, Allen Wirfs-Brock <[email protected]>
> 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.
But we are using it in a context where that isn't an issue.
> 2. Familiar from other languages and it works about the same here as it does
> in those
Arguably it doesn't. Java/C# static methods are not
inherited/over-ridable...of course that leads to the issue of constructor-side
inheritance.
>
> 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.
I don't think we have listed this as a design guideline anywhere. If a
word/constructor looks the same or even similar but has different semantics we
have instance confusion rather than instant knowledge.
We don't have to look familiar to get people to use JavaScript. They are going
to use it regardless. We may be past the point where these is much value in
mimicking other languages.
>
> 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.
I was speaking primarily from Smalltalk experience. Even though it had very
good tool support for class-side methods, there use is relatively rare.
Certainly less than 5% of all methods particularly if you discount the
class-side methods that implement and support the new method which is basically
the Smalltalk equivalent of the normal constructor.
They certainly shouldn't be particularly inconvenient to define. But they
aren't a central feature of OO design and probably don't deserve quite as much
language design attention as instance methods.
BTW, you may find some of the metric at
http://www.emunix.emich.edu/~ahmad/metrdes.htm interesting.
>
> > 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.
Exactly. I'm arguing that placing instance properties in an extension object
literal within the constructor is a way to reduce this confusion without adding
new property declarations that can only occur in the function bodies of
constructor functions.
>
> > 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.
Those languages don't have the this/super issue for static members because they
are just functions, not methods.
>
> 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.
The primary purpose of a class is to define the behavior (methods) of
instances. It is describing an abstraction over all the possible instances. The
behavior of the singleton class object is typically secondary to the primary
abstraction.
> 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.
Yes,but how long will it take you to learn it. Isn't it better when learning
something new to know that you don't understand it rather than to being mislead
into thinking it is something familiar when it really isn't.
Allen_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
