From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg T >>Think about it in the abstract. The Bird class makes >>the statement: >>all >>birds fly. Then you want to turn around and define a >>Bird that >>doesn't. >>Even doing >> >>def fly: >> pass >> >>makes no sense since what you've really done is to >>re-defined what >>'fly' >>means for this bird.
>Personally, I see nothing wrong with redefining a >method in a subclass. From my limited dealings with >multiple inheritance, it seems to me the less you have >to deal with it, the better off you are. Arguably this is an extreme case but the problem here is that the method was redefined to be diametrically opposed to its usual meaning. Kind of like derving a class from list and re-defining reverse to return the original list rather than the reversed one. Sure there may be some obscure reasons to do this or some valid sub-class to derive from list where this might make sense, but that's clearly not the intent of the original problem. >What do you all think about dealing with 'all birds >fly, but not these' based on an attribute? >Mass, or weight might be one factor... >Ostiches are too large to fly. (at least with their >current wing size) I'd still disagree because it starts with a statement about the class that is false: all bird fly. That's an incorrect statement about the base class and is the direct cause of the problems with the dervied classes. >>Again in the abstract: all >birds fly and for >>some >>birds that will mean that they don't. >> >>The only sensible solution to this that will cause >>the least confusion >>from a maintenance stanpoint and allow for the >>largest possible reuse >>is >>multiple inheritance for languages that support it. >I disagree, but then I come from the ruby language >which has an interesting take on MI. >Attributes and methods without the full complexity >of MI. >(though I'm certainly not an expert in ruby) Well, in retrospect I did overstate the case that it is the "only sensible solution." I could conceive of a class where there were a number of possible attributes that a member of that class could have and then maybe you would have a factory which would generate the proper subclass with the correct collection of attributes. And I agree that a profussion of classes may not be the best from a maintenance standpoint. But that's often the trade-off in OO class design...a profusion of classes that makes logical sense for the problem you are solving or something that you can actually maintain :-) Jeff _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
