Op 2005-11-24, Mike schreef <[EMAIL PROTECTED]>: > > "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,
But maybe what the user wants no longer guarantees correct working. > and many a time. I've been annoyed (in Java and MS christelijke vorm er van. > 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), Maybe that it is there is just an implementation detail. > but it's not accessable because the programmer was overly clever > and had been to OOP school. I think hiding something that is essentially an implementation detail is good abstraction and programming practice. > 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. I disagree. Suppose I have the following code. from module import __take_care__ __private_detail__ = ... I now have two variable that are flaged the same way, but they are not. __take_care__ is a private variable from an other module which I should use with extreme care not to break the other package. __private_detail__ on the other hand is just keeping private data for my own module, which I should care about as just any other variable in my module. It are other modules that should take special care if they should choose to import this variable. That is why I don't think the underscore prefixes are very usefull. They constantly flag to take care with a specific variable, while that variable is nothing special within the module itself. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
