Will Pierce
Posts: 2
Nickname: willp
Registered: Jul, 2008
|
|
Re: I wonder why this bothers people so much
|
Posted: Oct 1, 2008 9:04 PM
|
|
@J.Watson: I agree with your "mixed feelings" on this syntax, and think you've hit upon something important I'd like to underscore:
The particulars of the implementation of OOP methods are exposed, with self being explicitly received as a method parameter.
When you compare Perl's OOP to Python, the previous posters' references to currying make sense to me.
Because perl does not support bound-methods, there's two common ways to get around this limitation when you need to call an instance's method. One is to hang on to the function reference and the object and explicitly pass the instance reference ($self) as the first argument to the function reference ( $func_ref($obj_ref, @args); ). The second workaound is by using an anonymous subroutine reference as a closure that contains the instance object reference. For example:
# for object "$obj" with method "func"
$obj_bound_ref = sub { $obj->func(@_); };
# now you can call:
$obj_bound(42, "life");
# and it will invoke $obj->func(42, "life");
To me, that looks like currying in perl. I'm not saying this is good or bad or pretty, just showing the differences. (And how much we can appreciate bound-methods in Python.)
I think it does make a lot of sense to eliminate the mapping of obj.method(...) -> method(self, ...) and make "self" a keyword. I don't understand decorators (yet), as I'm returning to Python from 10 years away, and have a lot of catching up to do. So, I don't really understand what would prevent a language change that converted the explicit receipt of 'self' into an implicit receipt.
Are there other cases of this kind of pattern within python's history that we can learn from and follow, as a general form, or more self-consistent evolution? The only thing that comes to mind, for me, is the addition of yield() which changes a plain method into a generator.
Assuming yield() and generators are now well-loved, is there a lesson or pattern in there that we could follow?
What if instead of explicitly receiving the "self" reference as the first method parameter, what if instead we had to explicitly obtain the self reference?
class C(object):
def set_x(x):
s=self()
s.x = x
def get_x():
s=self()
return s.x
Now, I'm not particularly fond of this syntax, but it would move the "self" reference outside the method parameters... Maybe this would even help bypass the keyword issue, and perhaps the presence of a call to self() within a class method can deal with these decorator issues that I don't understand.
Obviously this would break all existing code, so that probably is enough reason to nix this suggestion. I'm just trying to toss some ideas around. Maybe this particular option doesn't actually boil down to anything different from jsut making 'self' a keyword, versus a function that only works in the context of an instance method.
What are some other ideas on how to pull 'self' out of the parameter list, in the most elegant and self-consistent (pythonic I suppose) way?
|
|
Previous Topic
