[Edu-sig] Refocusing on Capabilities (was PySqueak)

[Ian Bicking]

kirby urner wrote:
> On 5/26/06, Ian Bicking <ianb at colorstudy.com> wrote:
> 
>>
>> Inheritance as an abstraction used for communication.  In other words,
>> giving someone a class and telling them to subclass it.  Also, paying
>> attention to the class hierarchy when consuming objects is discouraged.
>>   Actually, paying any attention to the class when consuming an object
>> is discouraged.
>>
> 
> Several important standard library modules give you the classes to
> inherit from, and invite you to write your own methods.  HTML and XML
> parsing for example.

In comparison, ElementTree does such parsing without every subclassing. 
  Those specific modules were inspired by SAX and other libraries that 
came from the Java or Smalltalk worlds.  I think over time we've found 
better ways to do these things.

> I don't see where Python discourages subclassing.

As a language, no.  As a practice, *I* certainly would discourage it 
except when used internally as an implementation detail.  Where I do use 
it, I usually dislike the result.  I think this is a shift that's 
happened many places in the Python world, though I'm sure there are 
others who would disagree.

> Then I think you're talking about duck typing, i.e. if it behaves a
> certain way, it's OK to pass, and the type checking police won't be
> strict about it, like in Java.  That I understand.  However, I
> wouldn't call that discouraging -- I find it encouraging myself.  Too
> much type checking is a pain, and is what discourages Java use.

When working with objects, yes, you shouldn't care about their class. 
At which point it's up to the implementor if they subclass an existing 
class or recreate the functionality.  I this recreation is often the 
right choice, even when it means code duplication.

-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org