A 'Python like' language

[Mark Hahn]

> The fragility I see is that storing a function in a variable doesn't
modify
> the function, but storing it as an attribute of an object does...

Aha, I see our problem now.  In prothon, all variables are attributes of an
object.  There is no distinction between variables and attributes.  That is
part of the great simplification of Prothon.

>  they are in the dict of the instance, but not the class

See, another meaningless statement in classless Prothon.

> How is it possible to store a function from some object in another
> object for later use, e.g. as a callback?

Prothon is object-centric, not object-oriented or function-oriented.  You
would pass a call-back object, not a function:

   # module A
   call_back_obj = Object()
   def call_back_obj.fire():
      #code with closure to do whatever ...
   request_from_B(call_back_obj)

   # module B
   call_back_obj.fire()


"Andrew Bennetts" <andrew-pythonlist at puzzling.org> wrote in message
news:mailman.109.1080639892.20120.python-list at python.org...
> On Mon, Mar 29, 2004 at 10:46:42PM -0800, Mark Hahn wrote:
> > I need a better understanding of this.  You are suggesting the self stay
> > with a function like a closure of sorts?
> >
> > In my mind, anytime you say obj.func(), func is called on obj, no ifs
ands
> > or buts.  How could it be otherwise?  When would you want it otherwise?
>
> How is it possible to store a function from some object in another object
> for later use, e.g. as a callback?
>
> i.e. in Python syntax:
>
>     class C:
>         def __init__(self, callbackFunc):
>             self.callbackFunc = callbackFunc
>
>         def fireCallback(self):
>             self.callbackFunc()
>
>     c = C(someobj.method)
>
>     ...
>
>     c.fireCallback()
>
> > You say fragile.  What breaks?
>
> The fragility I see is that storing a function in a variable doesn't
modify
> the function, but storing it as an attribute of an object does, i.e.
>
>     f = someobj.method
>     x = f
>     x()
>
> behaves differently to:
>
>     otherobj.f = someobj.method
>     x = otherobj.f
>     x()
>
> Python solves this by wrapping functions found in classes as (un)bound
> methods (which keep track of the instance they were accessed from) -- but
> functions found on *instances* (i.e. they are in the dict of the instance,
> but not the class) are left alone.  It works well :)
>
> -Andrew.
>
>