Virtual functions are virtually invisible!

[Michael Hrivnak]

I can't believe you're saying that you will create a sub-class without
taking the time to understand the base class.  Seriously?  That right
there is why you are seeing method overrides that aren't documented.
How can you document something you don't understand?  Furthermore, how
can you have any confidence in your subclass if you don't understand
what its base class is doing?  Do you write unit tests?  How do you
know what to test if you don't understand the code you are
subclassing?

Suggesting that no developers document their methods?  Incredible.

Clobbered methods have "magic"?  Multi-layered "magic"?  Perhaps when
you take the time to 1) document the base class and 2) understand that
base class before subclassing it, that "magic" will start to look like
reasonable and logical processes.

Professional developers document their code.  They take the time to
understand the code they are working on.  If you don't want to do
those things, that's your business, and I'm sure you can find other
people who also don't do those things.  But I really don't think
you'll have much success changing the language to accommodate your
refusal to follow the most basic best practices.

Best of luck,
Michael

On Sun, Jul 10, 2011 at 10:35 PM, rantingrick <rantingrick at gmail.com> wrote:
> On Jul 10, 7:31 pm, Michael Hrivnak <mhriv... at hrivnak.org> wrote:
>> It sounds to me like you need a better IDE, better documentation,
>> and/or better code to work on and use.
>
> Yes the last two points are relevant here. However whilst IDE choice
> belongs to the user, documentation and code are in the hands of the
> developer; who's own selfish needs often outweigh that of the user AND
> community as a whole.
>
>> I don't understand why it's
>> difficult to look at a derived class as see what methods are
>> overridden.
>
> Well in my simple example it is VERY easy, WHY? Here are a few reasons
> why the clobbered methods are easy to spot (in both the base and
> derived classes)...
>
>  * Both exists within the same view frame. No need to flip back and
> forth between two windows.
>  * Both have only one method. The complexity increases exponentially
> by the number of methods AND the length of their respective code
> blocks!
>  * "Derived.m1" has a syntactical mark. You can clearly see which
> method has been clobbered WITHOUT even bothering to look at the base
> class.
>
> The only time you SHOULD have to look at the base class is to see what
> mandates the virtual method may impose. Does it require a Boolean
> return? An Integer? A Float? A List? Does it modify an object? Etc,
> etc?
>
>>  If you are working on the code, it is quite obvious what
>> methods exist in the base class.
>
> Let me correct your statement... IF you have an intimate understanding
> of the base. Heck what if the base is derived also? These things are
> NOT strictly single level you know.
>
>>  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.
>
> Not true, many times you don't need an intimate understanding of the
> base to wield a derived class. That's when the syntactical markers
> come in handy.
>
>> 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.
>
> How is adding syntactical markers to an otherwise obfuscation of
> virtual method clobbering going to confuse anyone? I would say the
> opposite is true. Python has used the forced convention "double-
> leading-and-trailing-underscores" to mark special methods since it's
> beginning. One reason for this convention is prevent name clashes
> HOWEVER the most important reason (i would argue) is for readability
> of source code. When Guido implemented this convention it was one of
> his greatest gifts to Python and the world (only to be outdone by
> forced indention!).
>
>> Referencing the Zen of Python: "If the implementation is
>> hard to explain, it's a bad idea."
>
> What if the code is "difficult" to read? Does "readability count" ring
> a bell?
>
>> 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.
>
> Yes. It is obviously poorly documented. And all the writer would have
> to do is put a little doc string there saying "clobbered virtual
> method here". HOWEVER, do you know how many folks bother to ACTUALLY
> do that? Huh? Do ya? None! Exactly.
>
>> 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.
>
> When a method has been clobbered any reader of such code NEEDS to know
> about it. WHY, well because usually clobbered methods have "magic"
> going on being the scenes. Sometimes many layers of "magic".
>
>> 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.
>
> I agree. However as we are all aware many "great Pythonistas" refuse
> to follow the style guide (*cough* freg! :). The only way to correct
> this problem is via a forced syntactical marker placed by the derived
> class's writer. Just like with "__IDENTIFIER__"
>
> READABILITY COUNTS!
> --
> http://mail.python.org/mailman/listinfo/python-list
>