On Jul 19, 2011, at 12:05 PM, Allen Wirfs-Brock wrote:

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

I agree. Other than "Java didn't have class-side inheritance and I did not miss 
it", I haven't heard a good reason to exclude it.

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

And we've heard from Rubyists such as Yehuda Katz on this point.


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

Don't forget Self :-P.

The functional programming (Scheme in spirit if not flesh) inspiration i took 
for JS also influences API design, avoiding silly single-method objects where 
functions will do.


es-discuss mailing list

Reply via email to