Unification of Methods and Functions

[Rich Krauter]

On Thu, 2004-05-13 at 17:59, David MacQuigg wrote:

> The one fundamental difference between methods and functions is the
> presence of instance variables in methods. 


To me, that statement is missing the whole point. OOP is not procedural
programming. That is the fundamental difference.

"Unifying" the syntax in an attempt to make it easier for your students
to learn probably won't accomplish what you want - one, I don't think
what you propose is easier or better, and two, and more importantly,
simply knowing python's (or any other language's) OOP syntax doesn't
automatically make you an OO guru. 

Knowing when, where and why to implement classes is much harder than
learning python's current syntax for building them. Your proposal
doesn't change that. 



>  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.

> 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.

I may be way off here, but I don't see how a global __self__ could work:

<not python>

class B:
    def __init__(name,data):
        .data = data*5
        .name = '***%s***'%name

class A:
    def __init__(name,data):
        .data = data  # __self__ is a?
        .obj = B()     # __self__ is now the B instance?
        .name = name  # now what?

a = A()

</not python>


Rich