Basic inheritance question

[Lie]

On Jan 15, 9:00 pm, Bruno Desthuilliers <bruno.
42.desthuilli... at wtf.websiteburo.oops.com> wrote:
> Lie a écrit :
>
>
>
> > On Jan 7, 2:46 am, Bruno Desthuilliers
> > <bdesth.quelquech... at free.quelquepart.fr> wrote:
> >> Lie a écrit :
>
> >>> On Jan 5, 5:40 pm, MartinRineh... at gmail.com wrote:
> >>>> Jeroen Ruigrok van der Werven wrote:
> >>>>> Shouldn't this be:
> >>>>> self.startLoc = start
> >>>>> self.stopLoc = stop
> >>>> Thanks! Of course it should. Old Java habits die slowly.
> >>> No, seriously it isn't Java habits only, most other languages wouldn't
> >>> need explicit calling of class name.
> >> Where is the "explicit calling of class name" exactly ?
>
> > Perhaps I was a bit tired when writing that (I wouldn't understand
> > what I wrote if I were you)... what I meant is most other languages
> > doesn't usually enforce us to explicitly state the containing class
> > name, which in python is generally called "self".
>
> 'self' (or whatever you name it) is not the "containing class name",

Current instance is what I meant, thanks for pointing out the
incorrect term I used.

> it's the first argument of the function - which usually happens to be
> the current instance when the function is used as a method.

And that's the point, self (or anything you name it) is almost always
the current instance and that makes it functionally the same as Me and
this in VB and Java.

> > Most other languages
> > 1) automatically assign the containing class' object
>
> s/containing class' object/current instance/
>
> > in a keyword
> > (Java: this, VB: Me) behind the screen,
>
> That's not very far from what a Python method object does -
> automatically assign the current instance to something. The difference
> is that Python uses functions to implement methods (instead of having
> two distinct contructs), so the only reliable way to "inject" the
> reference to the current instance is to pass it as an argument to the
> function (instead of making it pop from pure air).

It isn't very far, but Python makes it obvious about the assignment
(not behind the screen).

> There are some benefits to this solution. One of them is the ability to
>   dynamically assign functions as methods. So if you do have some
> function taking an object as first argument, you can easily turn it into
> a method.

Indeed, many languages doesn't allow dynamic assignment of function
which makes having an automatic assignment of current instance to Me/
this possible and with minimal harm.

> > and 2) automatically searches
> > variable name in both the local variable table and the containing
> > class variable table  (so to refer to a class variable named var from a
> > method inside the class, we only need to write var, not self.var as in
> > python).
>
> This - as you know - cannot work well with Python's scoping rules and
> dynamicity. Anyway, implicit object reference is definitively a
> BadThing(tm) wrt/ readbility, specially with multiparadigm languages
> (like Python or C++). Why do you think soooo many C++ shops impose the
> m_something naming scheme ?

Implicit object reference for the containing class has little harm, if
a class is so complex that there are more than 10 class-level
variable, then it is obvious that that class needs to be fragmented to
smaller classes. Remembering less than 10 variable and avoiding naming
collision among just 10 variable is not hard (and 10 is really too
many, most classes should only use 2-4 variables), especially if you
have a good IDE that employs Intellisense-like technology (IDLE has
it). And it is always a Bad Thing(tm) to use the same name for two
variable in the class and in function (which is the main and only
source of possible ambiguity) in ANY language, even in Python.

> Anyway, I actually know 3 languages (4 if C# works the same) that has
> this implicit 'this' (or whatever the name) 'feature', and at least 5
> that don't. So I'm not sure that the "most other languages" qualifier
> really applies to point 2 !-)

What's this 5 languages? Are they a mainstream, high-level languages
or lesser known, low-level languages? C-family, Java, and Basic are
the Big Three of high-level programming language.

> > In VB, Me is extremely rarely used,
>
> I used to systematically use it - like I've always systematically used
> 'this' in C++  and Java.

And that is what reduces readability. A proficient VB/C/Java
programmer would frown upon the extra, unneeded garbage as they
thought it was clear already that the variable refers to a class-level
variable. It is a different story if, like Python, the use of self is
enforced by the language, the self wouldn't be viewed as extra
unnecessary garbage.

> > in Python, self is all
> > over the place. Well, there is positive and negative to both sides,
> > convenience in VB, and flexibility in Python.
>
> As far as I'm concerned, there's *no* positive point in implicit object
> reference, and there has never been (and before some paranoid nutcase
> around accuse me of overzealous biggotry : I already held this very same
> opinion years before I discovered Python).

There is one major positive point: convenience and shorter code.
(isn't that two?)
As I've pointed out, there is little harm in class-level variable's
implicit reference.

> > Compare the following codes:
> > VB.NET:
> > Public Class A
> >     Dim var
> >     Public Function aFunction()
> >         return var
>
> Add three levels of inheritence and a couple globals and you'll find out
> that readability count !-)

It's the mental model that have to be adapted here, if the current
class is inheriting from another class, you've got to think it as
names from parent class as it is a native names, so you don't actually
need to know where the variable comes from since knowing where it
comes from is breaking the encapsulation (which, in Python is very
weakly implemented, which favors flexibility in many cases[1]).

[1] In Python, it is impossible to create a completely private
variable, which is the reason why the mental model of these other
languages doesn't fit Python.

> In any non-trivial piece of C++ code, and unless the author either used
> the explicit 'this' reference or the 'm_xxx' naming convention, you'll
> have hard time figuring out where a given name comes from when browsing
> a function's code.

If you're used to the implicit naming scheme it's easy to know where a
variable came from, if not the current scope, it's the class' scope
and searching two short variable tables (SHORT! Creating complex
classes is for stupid programmers[2]) at the same time isn't an
expensive operation for human-being, especially if memoization is
implemented.

[2] I used to create an extremely complex classes when I was still
green in programming, and that hits me back many times. Small, simple
class is A Good Thing(tm). Class should use less than 10 variables,
although the recommended number is 2-3 variables. Function names
should be as little as possible, the use of overloading and overriding
should be maximized.

As a final note:
I don't think implicit class reference is superior to explicit class
reference, neither do I think explicit class reference is superior to
implicit class reference. I think both have their own +s and -s. I
only pointed out that implicit do have its benefits, depending on the
language used (obviously Python wouldn't benefit from using implicit
behavior, due to it being extremely dynamic).