Making immutable instances

Mike Meyer mwm at mired.org
Fri Dec 2 03:47:36 CET 2005


bonono at gmail.com 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 <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.



More information about the Python-list mailing list