Unification of Methods and Functions

[Antoon Pardon]

Op 2004-05-14, David MacQuigg schreef <dmq at gain.com>:
> On 14 May 2004 12:29:32 GMT, Antoon Pardon <apardon at forel.vub.ac.be>
> wrote:
>>Op 2004-05-13, David MacQuigg schreef <dmq at gain.com>:
>>> 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.
>>
>>It already is. It is just that the function you have defined within
>>the class, is not the function you call through the object.
>
> In the current sytnax, we need a special "staticmethod" statement to
> define a method we can call without an instance.

Not realy, this would work just as well:

def __func(a,b):
   ...


class C:

    def __init__(self):

        self.func == __func
        

Why one wouldn't just write func and use it, instead of having
a staticmethod is beyond me, but it you want it be my guest.

> In the proposed
> syntax, there is no distinction between the different method styles,
> and no need for special syntax.  A "staticmethod" has the same
> arguments as normal method, and the same as an ordinary function.
> This is what I mean by having the same "calling sequence".
>
> For an example of how unification simplifies the presentation of OOP,
> see the first 8 pages of
> http://ece.arizona.edu/~edatools/Python/Prototypes.doc
>
>>> 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.
>>
>>There really aren't different calling sequences, just to different
>>related function.
>
> In the Animals.py example at http://ece.arizona.edu/~edatools/Python/
> there is a method Mammal.show().  Normally, the calling sequence is
> Mammal.show(cat1)
> where cat1 is just an instance needed to satisfy the requirement for a
> special first argument.  The method does not *use* cat1, and in
> general, there may not be an instance of every class available. If we
> convert Mammal.show to a static method, we don't need the special
> first argument.  The calling sequence is then
> Mammal.show()
>
> Do you understand what I mean by "different calling sequences"?

And do you understand it when I say, that it is not different
calling sequences but different functions. Two functions that
use the same name, are related in functionaly but are different.

Did you understand what happened with the "two" object?

>
><snip>
>
>>Having __self__ being
>>a global variable is disaster waiting to happen. What if a method
>>calls another method, what if you use threads?
>
> If a method calls another method, the same thing happens in the
> proposed syntax as in current Python.  Normally, the current instance
> doesn't change.

In current python no global variables are set by a call to a method.

> Python 2>>> Mammal.talk(self)
> Python 3>>> Mammal.talk()
> If you want to *over-ride* the normal behavior and *force* a specific
> binding:
> Python 2>>> Mammal.talk(cat2)
> Python 3>>> __self__ = cat2; Mammal.talk()
> I don't know why anyone would ever want to do this within a method,
> but it is possible.
>
> I don't understand the problem with threads.  Perhaps an example would
> help.

You talk about a global variable that is being set, What if two threads 
quasi simultaneously call a method. To what value is this global
__self__ set. 

-- 
Antoon Pardon