Virtual functions are virtually invisible!

[rantingrick]

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.