An "extend" operator is a natural companion to <|

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jul 18 15:40:51 PDT 2011


On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote:

> On Mon, Jul 18, 2011 at 10:32 AM, Allen Wirfs-Brock <allen at 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110718/9cad8273/attachment-0001.html>


More information about the es-discuss mailing list