Guido van Rossum wrote:
FWIW, I quite like the way how the core classes in Cocoa/NextStep are designed. For each container-ish object there's a mutable an immutable variant, where the mutable variant is usually a subclass of the immutable one. Examples: NSString -> NSMutableString NSData -> NSMutableData NSArray -> NSMutableArray NSDictionary -> NSMutableDictionary
This has its downside too though. A function designed to take an immutable class instance cannot rely on the class instance to remain unchanged, because the caller could pass it an instance of the corresponding mutable subclass! (For example, the function might use the argument as a dict key.) In some sense this inheritance pattern breaks the "Liskov substibutability" principle: if B is a base class of C, whenever a B instance is expected, a C instance may be used.
I'm not sure how much relevance this principle has in a language in which the inheritance tree has little meaning, but since I _am_ sure you read more books about this than I did, I'll take your word for it ;-) It's not so much the inheritance hierarchy that I like about the Cocoa core classes, but the fact that mutability is a prominent part of the design. I think Python would be a better language if it had a mutable string type as well as a mutable byte-oriented data type. An immutable dict would be handy at times. An immutable list type would be great, too. Wait, we already have that. Sure, tuples are often used for struct-like things and lists for that other stuff <wink>, but I don't think it's right to say you _must_ use them like that, and that seeing/using tuples as immutable lists is _wrong_. Just