Making immutable instances

[Mike]

"Ben Finney" <bignose+hates-spam at benfinney.id.au> wrote in message 
news:dm2rmv$aif$1 at rose.polar.local...
> Howdy all,
>
> How can a (user-defined) class ensure that its instances are
> immutable, like an int or a tuple, without inheriting from those
> types?
>
> What caveats should be observed in making immutable instances?

IMHO, this is usually (but not always) a mistake. (If you're programming a 
missle guidance system, or it makes your program go faster it's not a 
mistake :))
So are PRIVATE, CONST (all types), SEALED, FINAL, etc -- even the best 
programmer doesn't foresee what a user will want to do to make best use of 
his components, and many a time I've been annoyed (in Java and MS 
frameworks) by not being able to access/modify/subclass a member/class that 
I know is there because it has to be there (or because I can see it in the 
debugger), but it's not accessable because the programmer was overly clever 
and had been to OOP school.  A fine-grained capability architecture married 
to the language and runtime where I can declare my own level cleverness to 
override the programmer's would be nice, but I think Python's voluntary 
DoThis, _DoThisIfYouReallyHaveTo, and __You'dBetterKnowWhatYou'reDoing__ 
approach is a better way to go than the undefeatable keyword approach.

m

>
> -- 
> \         "Love is the triumph of imagination over intelligence."  -- |
>  `\                                                  Henry L. Mencken |
> _o__)                                                                  |
> Ben Finney