On Jul 4, 3:43 am, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote: > rantingrick wrote: > > what concerns me is the fact that virtual methods in derived > > classes just blend in to the crowd. > > I think we really need some > > sort of visual cue in the form of forced syntactical notation (just > > like the special method underscores). > > If you're suggesting that it should be impossible to override > a method unless it is specially marked somehow in the base > class, I think that would be a bad idea.
Sorry i did explain properly... No NOT marked in the BASE class but marked in the DERIVED class! My concerns are from a readability standpoint. Here's a naive example... class Top(object): def __init__(self): pass def m1(self): """overide""" return True def m2(self): print 'm2' def Derived(Top): def __init__(self): Top.__init__(self) def <overide>m1(self): return False My argument is this... """If class "Derived" exists in another module the reader has no idea which methods where clobbered and which were not WITHOUT being intimate with the entire code base.""" I suggest we solve this dilemma by forcing a syntax "tag" when declaring clobbering virtual functions. And if someone forgets to include the tag python would throw an exception. This has the effect of making the code MUCH easier to follow by the human readers. And it put NO constraints on the API. Also it has the added effect of warning unsuspecting programmers of name clashes that would otherwise not produce an error. > One of the principles behind the design of Eiffel is that > classes should *always* be open to modification in any way > by a subclass. The reason is that the author of a class > library can't anticipate all the ways people might want to > use it. Consequently Eiffel has no equivalent of C++'s > "private" declaration -- everything is at most "protected". > It also has no equivalent of Java's "final". Exactly! We should never put limits on what methods CAN be virtual. However, we CAN enforce a syntax that removes ambiguity from the equation. -- http://mail.python.org/mailman/listinfo/python-list