Making immutable instances

[Björn Lindström]

"Giovanni Bajo" <noway at sorry.com> writes:

> My feeling is that you're trying to get too much out of my words. I'm
> not trying to handcuff anyone. You seem to concentrate on me trying to
> avoid people adding attributes to my precious objects. It's not
> that. If I write a class and want it to be immutable, it is because it
> has to be so. If I write a queue class and I say that people shouldn't
> call pop() if it's empty, I mean it. If I enforce it with a
> RuntimeError, I'm not thinking I'm handcuffing someone. I don't see a
> ImmutableError to be so different from it.

But why would you call it that, when the object isn't actually
implemented as immutable?

It's pretty misleading to call an object immutable rather than saying
that it shouldn't be changed for some reason.

Throw an exception that describes why it doesn't make sense to change
that particular object instead.

As I said before, I think you're confusing the (in Python pretty
non-existent) concept of encapsulation with Python's immutable types,
which are immutable because the implementation demands it. (A fact I
hope will disappear at some point.)

-- 
Björn Lindström <bkhl at stp.lingfil.uu.se>
Student of computational linguistics, Uppsala University, Sweden