Smalltalk asPython

[Jan Theodore Galkowski]

On Tue, 26 Dec 2006 22:49:30 -0500, Jan Theodore Galkowski wrote:

>> Hi.
>>
>> One of the things I'd like to do with Python is find a way to
>> consistently implement Smalltalk's "loose methods".  This is a
>> capability whereby additional  methods can be added dynamically to
>> existing classes.
>
>You can't modify the built-in classes. I'm not sure that it is a good
>idea to allow built-ins to be modified. When I see an int, I like the
>fact that I know what the int can do, and I don't have to worry about
>whether it has been modified by some piece of code elsewhere.

Yes, that's the usual reaction on the part of Smalltalk newbies, too.
But the point is that the inserting of loose methods are just as much a
part of the current module as any other part of it, so the behavior of
the classes in the module needs to be understood in the context of the
amendments provided by the loose methods.  Similarly, the amendment of
these fundamental classes by a new class is an effect of the module and
if the module is used is understood to be something it does.

Also, sometimes adding such a loose method to a built-in class let
things be done with reflection easily, such as for "int":  Perhaps
there's an application context where the ordinal nature of "int"s is
more important than their cardinal nature, and such a reflection would
allow it to be easily implemented:

  int.ordinalQuizzle( self ) :

     return SpecialOrdinalQuizzleClass.ordinalQuizzleRealizer( self ) ;

It is considered bad form to amend the behavior of *existing* methods in
built-in classes of the class library.  Usually, loose methods *add* new
function only.


>But custom classes can be modified (the risk of some other code
>modifying it is the price you pay for being able to customise the class
>in the first place):

Yes, thank you, Steven, that was the point of my "isFoo" illustration.


[snip]

>Why not just say isinstance(x, Foo)?

And, yes, i know about "isinstance(.,.)".   I was using it purely for
easy illustration.

>> Like, then, what of other classes which descend from object and not
>> MutableObject?  You'd love to be able to set methods and attributes
>> within them.  Can you?

>Yes you can. Did you bother to try it?

Yes, I did, as illustrated above, with the MutableObject class.

The point is that you'd like all the intervening classes to inherit the
amendment at the root of the hierarchy within having to touch all the
lateral intervening classes or without having to redefine the
intervening classes.  Thus, my concern is probably overstated.  All that
needs to be done in practice is *know* what are the classes which derive
directly from, say, "int" in a system and insert the loose methods into
those, and the rest will follow.  It's just that if you can augment
"object" or "int", you don't even need to know that.

[snip]

Thanks for the thoughts.

  - Jan