Unification of Methods and Functions

[David MacQuigg]

On Thu, 13 May 2004 10:56:58 -0400, "Terry Reedy" <tjreedy at udel.edu>
wrote:

>"Antoon Pardon" <apardon at forel.vub.ac.be> wrote in message
>news:slrnca6d58.1i9.apardon at trout.vub.ac.be...
>> 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.
>
>My view is similar: in Python, a method is a dressed up (wrapped) function.
>'Unification of methods and functions' reads to me like 'unification of
>dressed-up bodies and naked bodies'.  What would that mean?  

By unification, I mean making the calling sequence identical for all
methods and functions.  No more special syntax for lambda functions,
static methods, etc.  No time wasted on these topics in a text like
Learning Python.  A simpler presentation of OOP, based on what
students already know at this point - functions, modules, and global
variables.

>One thing I
>like about Python is that there is only function-body syntax and not a
>separate, slightly different method-body syntax.  To me, having only one
>type of code body *is* unification.  So it is hard for me to see what is
>being proposed.  

The one fundamental difference between methods and functions is the
presence of instance variables in methods.  You can hide that
difference with the self.var trick.  You can hide it even further by
not using 'self', but some other word that looks just like the other
variable names in the function.  None of this removes the actual
difference, or makes learning about instance variables any easier for
the student.

The choice of how to identify instance variables is a minor issue.  I
think it is actually better not to *hide* the instance variables, but
to *highlight* them.  Ruby uses $var for instance variables.  Prothon
uses a leading dot, which is quite visible in most code editors.

The real issue is not self.var vs .var  It is the complexity resulting
from having different calling sequences.  Compare the 96-page
presentation of OOP in Learning Python, 2nd ed. to what I have written
at http://ece.arizona.edu/~edatools/Python/Prototypes.doc
In 7 pages, I can present the basics of OOP.  Adding examples and
exercises will probably bring this to 30 pages.  The key to this
simplification is not having to deal with unnecessary complexities,
like lambda functions, static methods, etc.

>Introducing a syntax like '.var' that would only be
>meaningful in a method and not a function would be dis-unification.

Actually, .var could be used in a function outside a class, just as
you can now use self.var in the current function syntax.  Before using
a function with .var, the global variable __self__ must be set. This
is normally done by calling the function from an instance.  Before
using a function with self.var, the first argument must be set.  This
is normally done by calling the function fom an instance.

To say that adding an instance variable to a function breaks unity is
like saying that adding a global variable to a function breaks unity.
Adding an instance variable to a function simply makes the function
dependent on an external variable.  Same with a global.

-- Dave