Making immutable instances

[Mike Meyer]

What is the use case for immutable strings? Why shouldn't strings be
mutable like they are in Scheme?

I don't know. Why shouldn't they?

Generally if I know I don't plan to mutate something, I'd want to make
it immutable so the runtime system can notice if I make an error.
It's like an "assert" statement spread through the whole program.

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.

<mike

 

[Mike Meyer]

Perhaps you missed my release announcement of the 'enum' package that
explains why Enum instances are immutable.

Yes, I did. I couldn't turn it up in Google, either. I did find a long
thread where you discuss the issue. Reading that, I found
justifications for having a constant hash value, and having immutable
attributes - but I've known about those for a long time.. Neither of
these constitutes an immutable instance.

Could I get you to recap the reason?

thanks,
<mike

 

[bonono]

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" ;-)

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.

 

[Ben Finney]

Yes, I did. I couldn't turn it up in Google, either.

It was the announcement for enum 0.3:

Could I get you to recap the reason?

"Since the values of an enumeration are directly reflected in the
values and attributes, Enum instances are immutable to preserve
this relationship"

 

[Mike Meyer]

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]

"Since the values of an enumeration are directly reflected in the
values and attributes, Enum instances are immutable to preserve
this relationship"

This justifies making the attributes immutable. But that's old hat - I
had that use case last year. It doesn't justify making the instances
immutable. Or if it does, I missed it.

thanks,
<mike

 

[bonono]

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.

Lose you, can you clarify ?

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.

um, that could be true(already forgot if I can do this in say C++). How
would I solve this kind of issue then, just curious.

 

[Alex Martelli]

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

So you'd have to make your class non-subclassable -- easy to do when
you're implementing a type in C, or with a custom metaclass. I guess
that's the motivation behind "final" classes in Java, btw -- arguably
one of the worst enablers of "designer hubris", of course;-)


Alex

 

[Mike Meyer]

Lose you, can you clarify ?

There are lots of use cases where you want your attributes to be
immutable. Rationals, enums, anything where you want your instance to
contain some used as a "value", or usable as a dictionary key that
might equal other instances, or - well, you should get the idea.

um, that could be true(already forgot if I can do this in say C++). How
would I solve this kind of issue then, just curious.

B&D languages have facilities for doing this kind of thing. Alex
Martelli has mentioned "final" classes in Java. C++ and Eiffel let you
declare an attribute as not modifiable by subclasses. Eiffel requires
that subclasses that override attributes (or methods, for that matter)
do so in a type-compatable manner, so you'd probably get a compile
error in your subclass in this case. There are certainly methods I've
never heard of as well. In Python, you can do things that try and
enforce this (I don't know how, because it's not something I think is
reasonable to want to do), but the language is also powerful enough
that I'd be surprised if they couldn't be defeated in some manner.

<mike

 

[Ben Finney]

This justifies making the attributes immutable. But that's old hat -
I had that use case last year. It doesn't justify making the
instances immutable. Or if it does, I missed it.

The Enum class promises that instances will have all the enumeration
values as instance attributes, and that all the instance attributes
are values in the enumeration. That requires that the set of
attributes on the instance not be changed after creation.

 

[Mike Meyer]

The Enum class promises that instances will have all the enumeration
values as instance attributes, and that all the instance attributes
are values in the enumeration. That requires that the set of
attributes on the instance not be changed after creation.

It doesn't say anything about that in the package, and there are no
docs in what's I downloaded from PyPI.

Doesn't live up to those promises, either.

But what's the point of promising that there won't be any attributes
that aren't values? Do you expect the user to know how to distinguish
implementation details from actual attributes(*), and get a list of
value names by filtering them from the attribute list? Wouldn't it be
easier to provide a method that returned a tuple of names - at least
easier than tuple(value.key for value in myenum)?

Sorry if you discussed this in the thread on the enum class, but I
didn't follow it.

<mike

*) Actually, the user is required to know implementation details, as
otherwise they'll have problems with value names that collide with
them.