By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,427 Members | 1,378 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,427 IT Pros & Developers. It's quick & easy.

loose methods : Smalltalk asPython

P: n/a
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.

In some respects, it's possible with Python. While "object" cannot be
touched, it's possible to define

class MutableObject( object ) : pass ;

and derive subclasses from MutableObject instead of object. Thereafter,
for instance, if devising a class

class Foo( MutableObject ) : isFoo = True ; ...

you can also put in its module

MutableObject.isFoo = False ;

So, at least for the inheritance hierarchy descending from
MutableObject, for an arbitrary object instance x,

x.isFoo

will return whether it's a Foo or not, effectively although not
transparently extending the builtin type(.).

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? These provide on-the-spot extensions of their
capability without having to subclass them (not such a big deal) or get
everyone to use the new subclass (a very big deal).

Comments? Suggestions?

Thanks,

-- Jan
Dec 27 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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.

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):
>>class MyInt(int):
.... pass
....
>>def odd(self):
.... return bool(self % 2)
....
>>MyInt.odd = odd
n = MyInt(5)
n.odd()
True

In some respects, it's possible with Python. While "object" cannot be
touched, it's possible to define

class MutableObject( object ) : pass ;

and derive subclasses from MutableObject instead of object. Thereafter,
for instance, if devising a class

class Foo( MutableObject ) : isFoo = True ; ...

you can also put in its module

MutableObject.isFoo = False ;

So, at least for the inheritance hierarchy descending from
MutableObject, for an arbitrary object instance x,

x.isFoo

will return whether it's a Foo or not, effectively although not
transparently extending the builtin type(.).
Why not just say isinstance(x, Foo)?

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?
>>class Shrubbery(object):
.... pass
....
>>Shrubbery.spam = lambda self, n: repr(self) + "spam"*n

Shrubbery().spam(5)
'<__main__.Shrubbery object at 0xb7d06aec>spamspamspamspamspam'

--
Steven.

Dec 27 '06 #2

P: n/a
Jan Theodore Galkowski <jt*********@alum.mit.eduwrote:
Comments? Suggestions?
<http://www.ruby-lang.org>

--
Luc Heinrich
Dec 27 '06 #3

P: n/a
Steven D'Aprano:
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.
I think it can be useful, there are many situations where you may need
to change the behavior of built-in dicts, etc, but:
- You need to keep code sorted and tidy to avoid problems. (This is
true for most of Python code too today. For example ObjectPascal gives
you less freedom to shoot yourself in the foot.)
- Allowing the built-in objects to be dynamically modified like that
may slow down the virtual machine some, if you don't design it quite
carefully. Psyco can help here too.

Bye,
bearophile

Dec 27 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.