On Jul 19, 2011, at 10:50 AM, Bob Nystrom wrote:

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

Yes, but it is a can that needs to be emptied.

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

Yes, but if that is the case there probably should have been a note that says 
that this property needs to be over-ridden when creating a subclass of Point.  
Even better, in that case would be do define AbstractPoint with zero and one 
methods that throw with a 'Subclass Responsibility' exception. (assume that the 
language has no built-in support for tagging properties as abstract.

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

This is a primary use case for class-side inheritance in Smalltalk. The 
collection class hierarchy is one place you can see their usage. Some design 
thought is usually required for inheritance to be effective as an an extension 
mechanism.  This applies whether you are on the class side or instance side.  
The reason and patterns for using 'this' as opposed to a fixed value are the 
same on both sides.

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

I actually think JS is very far from class-as-static-nominal-type OOP 
languages.  It is quite close to other dynamic OOPP languages.  The exemplars 
we need to be look at are  Smalltalk, Ruby, and Python.

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

Can't argue with that, other than to say which "other languages".

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

exceptions that prove the rule:  ? :   ,    ->
Not to mention the impact of operator overloading in C# and C++...

Just saying that there is probably some room for stretching the conventions if 
we have a good reason.

es-discuss mailing list

Reply via email to