Virtual functions are virtually invisible!

[Michael Hrivnak]

It sounds to me like you need a better IDE, better documentation,
and/or better code to work on and use.  I don't understand why it's
difficult to look at a derived class as see what methods are
overridden.  If you are working on the code, it is quite obvious what
methods exist in the base class.  If you're not willing to get an
intimate understanding of how the base class works, you probably
shouldn't be working on the subclass.  If the base class is difficult
to understand, it's probably poorly written and/or poorly documented.
Neither of these problems should be solved by adding complexity to the
language.  Referencing the Zen of Python: "If the implementation is
hard to explain, it's a bad idea."

If you are just using a library but not developing it, why does it
matter what methods are overridden?  As long as class "Derived"
behaves the way it is documented, who cares how it got that way or
what is going on behind the scenes?  If you need to read the code to
figure out how it works, then it's just poorly documented.

Django is a great example, because it is very well documented.  Most
users have little idea of what base classes are involved and what
features are overridden, because it doesn't matter when you are just
using the library.  When you need to write your own subclass of a
django class, then it might matter, and you should see my first
paragraph.

And in terms of "non-starters", any "Pythonista" who isn't willing to
adhere to the style guide and document their code wouldn't work on my
team for very long, if at all.  There is just no excuse for that.

Michael

On Sun, Jul 10, 2011 at 1:15 PM, rantingrick <rantingrick at gmail.com> wrote:
> On Jul 4, 3:43 am, Gregory Ewing <greg.ew... at 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
>