Unification of Methods and Functions

Antoon Pardon apardon at forel.vub.ac.be
Thu May 13 04:41:10 EDT 2004


Op 2004-05-12, David MacQuigg schreef <dmq at gain.com>:
> On 11 May 2004 18:54:56 -0700, moughanj at tcd.ie (James Moughan) wrote:
>
>>Sure; you have to have some understood conventions.  In effect that's
>>all any higher-level programming language than assembler is.  IMO, in
>>the case in point, the explicit self makes OO easier to undersstand;
>>YMMV, of course, as it does with Dave. :)
>
> I really hate to get involved in this "explicit self" debate, as I
> know it has been debated ad-nauseum for many years, but I wish people
> would not attribute to me a point-of-view that I do not have.  For me
> the "explicit self" is *not* the issue.  I have a slight preference
> for .var over self.var or $var, but this is a matter of personal
> preference, not an implicit vs explicit question.
>
> My definition of explicit is that you can tell the meaning of a
> statement without reference to the surrounding code.  By that
> definition all of the above forms are explicit.  They are all instance
> variables, and there is no other interpretation.  The choice between
> them is a *minor issue*, and I trust GvR to make these choices.
>
> The real issue is whether we can unify all forms of functions and
> methods.  This requires we do something different with 'self'.  From a
> unification standpoint, an equally acceptable solution is that we add
> 'self' to *all* functions and methods, whether they need it or not.

One could argue that all forms of methods and functions are unified.
It is just that python does some magic so that the method you
access from an object is not the actual function but the curried
function with the object.

If we have the following class:


class Incrementor:

  def __init__(self, first_value):
    self.value = first_value

  def next(self):
    result = self.value
    self.value += 1
    return result
    

We could rewrite it as follows without methods -- except for __init__ --
and get the same object functionality :


class Incrementor:

  def __init__(self, first_value):

    def next(self):

      result = self.value
      self.value += 1
      return result

    self.value = first_value
    self.next = curry(next)(self)  # or self.next = curry(next,self)
                                   # depending on the curry version


Now if explaining currying functions to your students will help
them understand, I don't know, although I don't find it that
complicated.

-- 
Antoon Pardon



More information about the Python-list mailing list