"Ben Finney" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 -- http://mail.python.org/mailman/listinfo/python-list