Unification of Methods and Functions

[David MacQuigg]

On Wed, 12 May 2004 15:42:56 +1200, Greg Ewing
<greg at cosc.canterbury.ac.nz> wrote:

>David MacQuigg wrote:
>> Prothon is trying to make binding explicit, 
>
>That's not entirely true. Prothon currently has
>cat1.meth() doing binding just as implicitly as
>Python.

You are correct.

>What it doesn't do is bind implicitly when you're
>not going to call the method right away, which
>from a Python perspective is decidedly odd,
>not to mention rather inconsistent.

Yes.  The example I had in mind was

cat1 = Cat()  # instance of class Cat
bound_func = cat1.func
unbound_func = Cat.func

Python's implicit rule, which Prothon is not following, is -- You get
a bound function if you access it from an instance.  You get the
equivalent unbound function if you access it from the instance's
class.  I made my example deliberately perverse by not following
Python's conventions on capitalizing class names, and by naming my
function 'meth' and my method 'func'.

As long as we follow the conventions, and we don't chose misleading
names, I'm happy with the way Python handles binding, even thought it
is "implicit".  I would change my mind if it became apparent that many
users were confused.  In that case, a little extra typing to show an
explicit binding would be justified.

In my proposed syntax, the default bindings follow Python's current
rules.  If you ever need to *over-ride* those rules, you can do so by
explicitly setting __self__.  Except for code intended for
diagnostics, or for introspection, I believe the user can safely
ignore __self__.

-- Dave