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

> On Mon, Jul 18, 2011 at 3:40 PM, Allen Wirfs-Brock <al...@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.

es-discuss mailing list

Reply via email to