Bruno Desthuilliers
1/15/2008 2:00:00 PM
Lie a écrit :
> On Jan 7, 2:46 am, Bruno Desthuilliers
> <bdesth.quelquech...@free.quelquepart.fr> wrote:
>> Lie a écrit :
>>
>>> On Jan 5, 5:40 pm, MartinRineh...@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.