Making immutable instances

[Mike Meyer]

Re: Making immutable instances

bonono@gmail.co m writes:[color=blue]
> Quoting the frequently used term "Practicali ty beats purity". If I have
> a practical problem/needs now and it solves it, why not use it ?[/color]

In other words, you have a use case. Cool. Please tell us what it is -
at least if it's better than "I think that's bad style."

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[bonono@gmail.com]

Re: Making immutable instances


Mike Meyer wrote:[color=blue]
> bonono@gmail.co m writes:[color=green]
> > Quoting the frequently used term "Practicali ty beats purity". If I have
> > a practical problem/needs now and it solves it, why not use it ?[/color]
>
> In other words, you have a use case. Cool. Please tell us what it is -
> at least if it's better than "I think that's bad style."
>[/color]
Huh ? I said that if I need "immutable instance", I won't hestiate to
use __slot__, I didn't say I have a need.

In other words, I see __slot__ as a solution to the problem, I am not
saying I have the problem in the first place. The "practicabi lty beats
purity" is used to support this using __slot__ situation, not about the
need of immutable instance.

[Mike Meyer]

Re: Making immutable instances

bonono@gmail.co m writes:[color=blue]
> Mike Meyer wrote:[color=green]
>> bonono@gmail.co m writes:[color=darkred]
>> > Quoting the frequently used term "Practicali ty beats purity". If I have
>> > a practical problem/needs now and it solves it, why not use it ?[/color]
>> In other words, you have a use case. Cool. Please tell us what it is -
>> at least if it's better than "I think that's bad style."[/color]
> Huh ? I said that if I need "immutable instance", I won't hestiate to
> use __slot__, I didn't say I have a need.[/color]

A need implies a use case. Yes, you didn't say you had one, you said
if, and I jumpted the gun.

Lots of people seem to want immutable instances. Nobody seems to have
a use case for them.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Paul Rubin]

Re: Making immutable instances

Mike Meyer <mwm@mired.or g> writes:[color=blue]
> Lots of people seem to want immutable instances. Nobody seems to have
> a use case for them.[/color]

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

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.

[Ben Finney]

Re: Making immutable instances

Mike Meyer <mwm@mired.or g> wrote:[color=blue]
> Lots of people seem to want immutable instances. Nobody seems to
> have a use case for them.[/color]

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

--
\ "Hanging one scoundrel, it appears, does not deter the next. |
`\ Well, what of it? The first one is at least disposed of." -- |
_o__) Henry L. Mencken |
Ben Finney

[Mike Meyer]

Re: Making immutable instances

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> writes:[color=blue]
> Mike Meyer <mwm@mired.or g> writes:[color=green]
>> Lots of people seem to want immutable instances. Nobody seems to have
>> a use case for them.[/color]
> What is the use case for immutable strings? Why shouldn't strings be
> mutable like they are in Scheme?[/color]

I don't know. Why shouldn't they?
[color=blue]
> 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.[/color]

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

[Mike Meyer]

Re: Making immutable instances

Ben Finney <bignose+hate s-spam@benfinney. id.au> writes:[color=blue]
> Mike Meyer <mwm@mired.or g> wrote:[color=green]
>> Lots of people seem to want immutable instances. Nobody seems to
>> have a use case for them.[/color]
> Perhaps you missed my release announcement of the 'enum' package that
> explains why Enum instances are immutable.[/color]

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
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[bonono@gmail.com]

Re: Making immutable instances


Mike Meyer wrote:[color=blue]
> 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.
>[/color]
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]

Re: Making immutable instances

Mike Meyer <mwm@mired.or g> wrote:[color=blue]
> Ben Finney <bignose+hate s-spam@benfinney. id.au> writes:[color=green]
> > Mike Meyer <mwm@mired.or g> wrote:[color=darkred]
> >> Lots of people seem to want immutable instances. Nobody seems to
> >> have a use case for them.[/color]
> > Perhaps you missed my release announcement of the 'enum' package
> > that explains why Enum instances are immutable.[/color]
>
> Yes, I did. I couldn't turn it up in Google, either.[/color]

It was the announcement for enum 0.3:

<URL:http://groups.google.c om/group/comp.lang.pytho n/browse_thread/thread/ea5991de0459d5c 4/>
[color=blue]
> Could I get you to recap the reason?[/color]

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

--
\ "I can picture in my mind a world without war, a world without |
`\ hate. And I can picture us attacking that world, because they'd |
_o__) never expect it." -- Jack Handey |
Ben Finney

[Mike Meyer]

Re: Making immutable instances

bonono@gmail.co m writes:[color=blue]
> Mike Meyer wrote:[color=green]
>> 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.[/color]
> By design, this is a "don't use" feature so it would be very hard to
> find a "use case" ;-)[/color]

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.
[color=blue]
> 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.[/color]

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

[Mike Meyer]

Re: Making immutable instances

Ben Finney <bignose+hate s-spam@benfinney. id.au> writes:[color=blue]
>
> "Since the values of an enumeration are directly reflected in the
> values and attributes, Enum instances are immutable to preserve
> this relationship"[/color]

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
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[bonono@gmail.com]

Re: Making immutable instances


Mike Meyer wrote:[color=blue][color=green]
> > By design, this is a "don't use" feature so it would be very hard to
> > find a "use case" ;-)[/color]
>
> 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.[/color]
Lose you, can you clarify ?
[color=blue]
> 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.
>[/color]
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]

Re: Making immutable instances

Mike Meyer <mwm@mired.or g> wrote:
...[color=blue]
> 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[/color]

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]

Re: Making immutable instances

bonono@gmail.co m writes:[color=blue]
> Mike Meyer wrote:[color=green][color=darkred]
>> > By design, this is a "don't use" feature so it would be very hard to
>> > find a "use case" ;-)[/color]
>> 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.[/color]
> Lose you, can you clarify ?[/color]

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.
[color=blue][color=green]
>> 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.[/color]
> 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.[/color]

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
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Ben Finney]

Re: Making immutable instances

Mike Meyer <mwm@mired.or g> wrote:[color=blue]
> Ben Finney <bignose+hate s-spam@benfinney. id.au> writes:[color=green]
> > "Since the values of an enumeration are directly reflected in
> > the values and attributes, Enum instances are immutable to
> > preserve this relationship"[/color]
>
> 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.[/color]

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.

--
\ "The future always arrives too fast, and in the wrong order." |
`\ -- Alvin Toffler |
_o__) |
Ben Finney