Re: OO Programming (kinda like BDSM, but more painful and less fun...)
Re: OO Programming (kinda like BDSM, but more painful and less fun...)
- Subject: Re: OO Programming (kinda like BDSM, but more painful and less fun...)
- From: garbanzito <email@hidden>
- Date: Sun, 30 Dec 2001 23:14:57 -0700
at 2001 12 30, 15:49 +0000, they whom i call has wrote:
I imagine this is a scope issue, but don't understand why.
[...]
good puzzler. it's more a scoping, than an OO issue. here's
my analysis with a solution at the end:
This doesn't [work]:
script x
script y
on foo()
beep 2
end foo
end script
property z : {}
end script
script z --(z is outside x)
y's foo()
end script
y is scoped globally. the compiler doesn't care that there
isn't a global y because the binding (not the scope) will be
dynamic (at runtime). the compiler sets things up so if
there is a global y at runtime, it's foo() will be called.
set x's z to z --(chuck z into x at runtime)
this makes z an element of x, but does not make x z's parent
or change the scope of the reference to y within z...
tell x's z to run
you are still running the _script_ z, just referring to it
indirectly as x's _element_ z. (calling them both 'z' clouds
the issue, because each is a distinct item regardless of
their names.) the x's z may be within a scope where y is
defined, but when it is assigned a value of the global
script z, the scope of script z doesn't change.
But with a slight tweak it does [work]:
script x
script y
on foo()
beep 2
end foo
end script
property z : {}
end script
script z
x's y's foo() --(note change from previous example)
end script
here you scope y at compile time to x's context, so z's
context doesn't have any effect on the result.
set x's z to z
tell x's z to run
works because y was in scope anyway. to illustrate this, the
last two lines could have been:
set alpha's z to z -- assume alpha has a property z and a script y
tell alpha's z to run -- z will still use x's y, not alpha's
here's a workaround that turns things on their head to
simulate dynamic scoping of y. it appears that the scope of
handlers *is* dynamic and will force dynamic scoping of
references to script objects, even though the scope of a
simpler script object references is static! is this sloppy
implementation or am i just not grokking its logic?
(i had to reorder x & z because the compiler for some reason
doesn't allow an element of a script to be set to another
script that precedes it, even though the assignment won't
happen until runtime.):
script z
property psuedo_scope : {}
psuedo_scope's get_y()'s foo()
end script
script x
script y
on foo()
beep 2
end foo
end script
on get_y()
y
end get_y
end script
set z's psuedo_scope to x -- or any other script with a get_y() handler
tell z to run
--
steve harley email@hidden