16
Unlike most [most popular] object-oriented languages, which use a keyword to refer to the object that is "target" of a method call (commonly called this
), the Python language requires every method to have an additional parameter (the first, and by convention usually called self
) to represent this object. This seems to me a case of code Boilerplate, that you have to write always but that doesn’t add much...
(Note: this is a particular case of the use of "pronouns" in code, something possible in the Lisp language and used extensively in Perl)
Is there any concrete reason for not use one this
implicit [in the design of a general purpose language or DSL]? Any use case where the explicit parameter allows/facilitates something that would be unfeasible if it were implicit?
Remarks:
Even in Python, if you get a reference to a method of an object it comes as a
bound method
, and you call him by omitting the first argument:class Foo(object): def bar(self, a, b): return self.x + a + b foo = Foo() bar = foo.bar bar(10, 20) # 10 é "a" e 20 é "b"; o "self" já está atribuído para você
...the use of a special function to "reassign" the same to a different object:
foo2 = Foo() bar.__func__(foo2, 10, 20)
Nothing prevents a "normal" function from being transformed into a method by an operation similar to currying:
def encadear(a, b): a.proximo = b class Foo(object): append = lambda self, b: encadear(self, b) appendTo = lambda self, a: encadear(a, self)
(through a more user-friendly syntax, of course... and in that case, prohibit the use of
this
in functions declared outside the context of an object would be desirable - unlike what happens with Javascript for example)...or that a method is transformed into a normal function by a reverse operation:
var foo = { bar:function(a, b) { return this.x + a + b; } }; var bar = foo.bar; var foo2 = { x:10 }; bar.call(foo2, 20, 30); // O método original mantém o this explícito, // mas ainda podemos atribuí-lo explicitamente
Therefore, I see no reason to explain the self
, just unnecessary code... Is there a strong argument in favor, perhaps coming from the author(s) (s) of the Python language(s)? (or other language that uses similar strategy)
It’s a great example, I don’t know the language Lua but for what it showed here it is more "sane" than Python and Javascript. This syntactic sugar you mentioned is quite similar to making a currying in the first argument. It only seems to me that when using the
:
, the lexical scope ofself
becomes so problematic when thethis
implicit, no? Think of a closure where both the function Outer as to inner use this syntactic sugar (if this is supported by Lua of course): in that case there will be capture of the nameself
in internal, that neither the problem ofvar that = this
in Javascript.– mgibsonbr
@mgibsonbr: The
:
is just a syntactic sugar (abbreviation) that is completely equivalent to if you had written a parameter calledself
at hand. http://www.lua.org/manual/5.2/pt/manual.html#3.4.10– hugomg
Hehe I understand! What I’m saying is that its use makes it so amenable to a capture as to a
self
implicit (i.e. equivalent to if you had written a parameter calledself
on hand in both internal and external functions). But I agree that there is advantage in this case: the programmer always has the option of not use syntactic sugar whenever it causes problems...– mgibsonbr
@mgibsonbr: The inside function will not declare a self parameter so shadowing will not occur. Unlike Javascript, the self statement only occurs if you write it explicitly (with an explicit parameter or with
:
).– hugomg