On Mon, Jul 18, 2011 at 6:50 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:

> 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); }
>   }
> Good point, though it does open the should-constructor-objects-inherit can
of worms.

> 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();

It's possible that he did think about it, and thinks the solution should be
to define an appropriate zero() method in Point3D.

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

That works fine for zero() but what about unit() or other factory functions?
I can imagine convoluted solutions to that, but not anything that's simpler
and cleaner than just defining appropriate factory methods in the derived
class instead of trying to inherit them.

I'm not sure how effective it is to try to inherit constructor-like
functions. If you're using inheritance, that implies to me that the derived
object adds its own state that needs proper initialization. Given that, I
worry that it would be more trouble than it's worth to define methods in
base objects that can somehow anticipate that.

> 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

Absolutely right. I don't want to turn JS into Java (ugh), and I don't think
anyone else does either. I do think JS isn't as far from other OOP languages
as it might like to believe, and we can occasionally use that to our

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

I may be overly optimistic, but I think you can have both: a syntax that
isn't totally foreign to people coming from other languages but is also
expressive and JS-centric enough to be pleasant to use by experts. I don't
know if the current class proposal is that, but I think it's important to
try for both before we settle and choose to exclude one set of users.

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

Agreed, but I think it's important to keep in mind where it's coming from
too. For better or worse, its legacy is that it marries some relatively
uncommon semantics with a syntax largely inspired by Java (and C, C++, C#,
et. al). To me that means curly blocks, semicolons, keywords for structure
and flow control, and usually only operators for arithmetic and logical

While I'm personally not a huge fan of that style, JS is pretty consistent
with it. I'm 100% on board with bringing JS's unique features to the surface
in a clearer way but I'd be sad if we did that at the expense of syntactic
consistency. I think Objective-C is a cool language, but it's clearly and
unpleasantly two languages jammed into one (with "[]" as the duct tape
holding them together). I think we can do better than 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.

I think a lot of us would love to have a time machine to go back and fix
that (and block scope!). Until we can do that, I think the best we can hope
to do now is to move the language forward while getting the most use out of
its legacy "features" that we can.

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 agree we shouldn't blindly ape other languages (especially ones we,
honestly, probably aren't too fond of). But programming languages are human
languages and we may make it easier for others to speak JavaScript if we can
keep in mind the languages they already know. Our users aren't blank slates
and it's up to us to decide if that's a liability or a benefit.

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.

True, especially now that we've got real modules coming.

- bob
es-discuss mailing list

Reply via email to