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 -- http://mail.python.org/mailman/listinfo/python-list