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

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jul 19 12:05:51 PDT 2011


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

> On Mon, Jul 18, 2011 at 6:50 PM, Allen Wirfs-Brock <allen at 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.

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


More information about the es-discuss mailing list