Basic inheritance question

[Bruno Desthuilliers]

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", 
it's the first argument of the function - which usually happens to be 
the current instance when the function is used as a method.

> 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).

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.

> 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 ?

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 !-)

> In VB, Me is extremely rarely used,

I used to systematically use it - like I've always systematically used 
'this' in C++  and Java.

> 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).

> 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 !-)

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.