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:

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

  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?

> 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.

 We may be past the point where these is much value in mimicking other
> languages.

What makes you say that?

> 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.

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

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.

My rough calculation was around 10% looking at Closure JS code.

> 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.


> 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.

True, but secondary still matters.

> 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.

I don't like being led astray, certainly. Personally, I do like learning
"this is kinda like a foo" and then later having that refined to "but it
doesn't bar and it bazzes". I'd rather that than having to learn a new
concept from a blank page only to reach the end and realize "hey, this is
75% like a foo."

- bob
es-discuss mailing list

Reply via email to