[EMAIL PROTECTED] writes: > Mike Meyer wrote: >> That's not a use case, that's a debugging aid. The same logic applies >> to adding type declarations, private/public/etc. declerations, and >> similar B&D language features. It's generally considered that it's not >> a good enough reason for adding those, so it doesn't really constitute >> a good enough reason for making an instance immutable. > By design, this is a "don't use" feature so it would be very hard to > find a "use case" ;-)
But I can think of use cases for instances with no mutable attributes, which is another "don't use" case. If I can do that, those proposing that instances ought to be immutable should be able to come up with a use case. > I can only think of a situation which may not be able to detect by > testing. Say I have a module version 1 which is used by app version 1. > In your app, you attach your own attribute to an instance of the > module. Everything is fine. Now module becomes version 2 which happens > to use the same attribute name that you hang on it and the program > starts to behave strangely because they are stepping on each other's > foot without knowing it. If everything is done by the same group of > people with good communication, it may be possible to detect it. But if > the module is done by a third party, and the app is done by yet another > third party. The situation becomes complicated. Say if under debian, I > do an apt-get python-sqlobject which may be used by multiple apps. If > one of them happens to do it this way, this senario may happen. This is a problem with OO in general, not with not having immutable instances. You get the same problem if, instead of attaching attributes to your instances, I subclass your class and add the attribute in the subclass (which I can do even if both my instances and yours are immutable). In short, immutable instances don't solve your problem, so this doesn't work as a use case. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list