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

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jul 18 18:50:36 PDT 2011


On Jul 18, 2011, at 4:50 PM, Bob Nystrom wrote:

> 
> 
> On Mon, Jul 18, 2011 at 3:40 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 
> On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote:
>> 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 did say "about the same" and not exactly the same. Naturally there are some differences, but there are plenty of similarities too. I don't think a programmer from C++/C#/Java would find this astonishing at all, and would probably have little trouble inferring what it means:

But if you were coming from a language where constructors (classes) were real objects with real methods that could reference this and which were inherited by subclass object you might look at the issue quite differently

> 
>   class Point {
>     static zero() { return new Point(0, 0); }
>   }

in fact you might look at the above zero method and say, Oh, that's buggy.  He didn't think about what will happen when somebody creates Point3D as a subclass and then codes:  Point3D.zero();

A better definition would be:

class Point {
    static zero() { return new this(0, 0); }
  }
or, probably even better this:

class Point {
    static zero() { return new this( ); }
  }

and you probably would want to make sure that the constructor always return the origin for the default no argument case.

The main point is that to do the right think here it is important to not think of it as being just like C++/C#/Java


>   
>   var p = Point.zero();
> 
>> 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.
> 
> Does it need to be written down as a guideline to be a good idea?

The real issue is what is both looks and acts similarly enough to make this a good rule to apply.  There is clearly some disagreement about this particular case and a hazard of this general rule.
>  
> 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.
> 
> That's probably true (yay browser lock-in) but I don't know that's what I'd call a great attitude for usability. I'm imagining that as a bumper sticker. JavaScript: you're going to use it regardless.

I wasn't trying to make a statement about usability.  I actually think usability (and readability) of language features is very important.  But I'm more concerned about the long term usability of the language by people who know the language well then I am about short term ease of adoption by somebody today who is knowledgeable about some in a legacy language. JavaScript is here and and going to remain here for a very long time.  I want it to hold together on its own terms and to be most usable for people for whom it is their first and primary programming language.

> 
>  We may be past the point where these is much value in mimicking other languages.
> 
> What makes you say that?

JavaScript is its own unique combination of concepts and features. I think that some of the more significant warts in JavaScript (including the new operator, instanceof, and some aspects of constructor functions) are a direct result of such mimicry.  Rather than continuing to just graft on features from other language we need to be evolving JavaScript on its own terms.  This needs to be informed by knowledge of the successes and failures of other language designs and many other things.   But I see little value in mimicry for its own sake.


>  
> I was speaking primarily from Smalltalk experience.  Even though it had  very good tool support for class-side methods, there use is relatively rare.
> 
> I'm not a Smalltalker but my impression is that Smalltalk culture was more open to defining things as instance methods where a Javascripter would likely make a static method on some constructor. Especially in recent years where monkey-patching existing protos is considered bad form, that leads to fewer instance methods and more static ones. Likewise, for-in loops discourage adding methods on prototypes.

This may well be the case, but is it something we want to encourage for the next 50 years? Most behavior belongs on instances because it is the instance that model the computation system of the program.  Instances are what OO design and programming is all about.  If we make it easy to define instance behavior and harder to define "static" behavior that is probably a good think in the long run.

> 
> Even in Harmony, many of the new methods being adding are "static": Proxy.create(), Proxy.createFunction(), Proxy.isTrapping(), Object.getPropertyDescriptor(), Object.getPropertyNames(), Object.is(), Number.isFinite(), Number.isNan()... If anything non-instance methods are becoming more important in JS as time goes on (though modules might change that).

Brendan and I recently had a discussion about some of these and it isn't clear that they are all in the correct places.  Of the ones you mentioned, I'm not so sure I would call Proxy a constructor.  (you never say, new Proxy() right?) it is really a factory object which means the methods you name are instance side.  The Object refection methods were put on object because it was a convenient  "namespace" object. But that's not a style I would want to encourage for complex user applications.  isFinite and isNaN probably should go on the instance side.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110718/f857ef1e/attachment-0001.html>


More information about the es-discuss mailing list