In article <[EMAIL PROTECTED]>, "Paul McGuire" <[EMAIL PROTECTED]> wrote: [ ... lots of interesting discussion removed ... ]
> Most often, I see "is-a" confused with "is-implemented-using-a". A > developer decides that there is some benefit (reduced storage, perhaps) > of modeling a zip code using an integer, and feels the need to define > some class like: > > class ZipCode(int): > def lookupState(self): > ... > > But zip codes *aren't* integers, they just happen to be numeric - there > is no sense in supporting zip code arithmetic, nor in using zip codes > as slice indices, etc. And there are other warts, such as printing zip > codes with leading zeroes (like they have in Maine). I agree, but I'm not sure how easily this kind of reasoning can be applied more generally to objects we write. Take for example an indexed data structure, that's generally similar to a dictionary but may compute some values. I think it's common practice in Python to implement this just as I'm sure you would propose, with composition. But is that because it fails your "is-a" test? What is-a dictionary, or is-not-a dictionary? If you ask me, there isn't any obvious principle, it's just a question of how we arrive at a sound implementation -- and that almost always militates against inheritance, because of liabilities you mentioned elsewhere in your post, but in the end it depends on the details of the implementation. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
