Why self?

[Andrew Koenig]

Louis> This one is lost on me.  Sorry, I'm not operating at your
Louis> level.  What is the point?  I advocated initializing object
Louis> variables in a mandatory __init__ statment.  So you should have
Louis> added

Louis>        def __init__(self):
Louis>            name=None

But that's extra code.  I thought the whole point was to get rid of
extra code, not move it around.

>> 2) Methods are just functions that happen to be attributes.
>> In other words, we could have written this:

>> class Thing:
>>   def __init__(self):
>>     setname(self)

>> def setname(x):
>>   x.name = "Thing"

>> def printname(self):
>>   print self.name

>> Thing.printname = printname

>> t = Thing()
>> t.printname()

>> effectively transforming printname into a method, even though it
>> does not have the form of a method when it is written.

>> It seems to me that dropping the explicit "self" would make these
>> two programs much messier.  In what way then is it cleaner?

Louis> Hmmm...a pretty bizzare example or else I just don't have
Louis> enough programming experience.  I've never done anything close
Louis> to that.

My experience is that ``bizarre'' is often just another way of saying
``unfamiliar.''

Louis>  I will have to rely on others experience (including yours,
Louis> which I know is substantial).  Is this realistic or are you
Louis> just pulling out a pathological example for argument?  After
Louis> all, I don't think it's the duty of a language design to
Louis> completely protect the programmer from foolish code (for want
Louis> of a better phrase).  At some point the language has to just
Louis> give up trying to interpret things and "raise and exception."

What about someone who wants to write several classes with methods
that behave exactly the same way?  Doesn't it make sense to write that
code once, and then install references to it in each of those classes?

What about code that wants to build up objects with particular
properties by installing methods dynamically in those objects
according to the requested specifications?

Louis> Tell you what. You're a smart guy (not sarcastic, I mean it).
Louis> Why not apply your considerable knowledge to finding a solution
Louis> to the issue of requiring "self."  prefixes?  It's apparent
Louis> that lots of people would like to lose that requirement.  I'm
Louis> sure you can demolish my off-the-cuff suggestion at some point.
Louis> I'm a bush-league amateur. But when you do that you will turn
Louis> around to see that the issue itself is still there.  What would
Louis> you do?

The point that I'm trying to make is that requiring "self" has some
advantages, in that it makes certain kinds of programs easier to write
than they would be otherwise.  I've given two examples of such
programs: those that add attributes dynamically to objects and those
that define methods outside of the corresponding classes.  Doubtless
there are others.

Because requiring "self" has some advantages, as well as the disadvantages
that you and others have mentioned, it's a matter of opinion as to whether
a solution to the problem would create other problems.  For that reason,
I'm not inclined to go looking for a detailed solution--especially as
any solution would have to avoid breaking existing code.

-- 
Andrew Koenig, ark at research.att.com, http://www.research.att.com/info/ark