Re: Scope of globals, parents and children
Re: Scope of globals, parents and children
- Subject: Re: Scope of globals, parents and children
- From: Brennan Young <email@hidden>
- Date: Wed, 23 May 2001 00:26:57 +0200
- Organization: Magic Lantern
Sander wrote
>
I must organize my current handlers into groups (grouping them as makes sense
>
to me, taking into consideration both what they do, and what data they do or
>
don't share); declaring each group to be a script object; and then (if I want
>
to) save 1 or more of these script objects as separate compiled scripts that
>
are loaded through "load script".
Exactly. You've boiled down the process of converting a procedural script to an
object oriented one into a single paragraph!
>
That way, even _if_ a 'need' for globals
>
remains, they would only have to be global within the relevant script object.
In which case a property would do just as well.
>
In addition it would be good to write a script object that manages all this;
>
one that, on being requested a value, tells other script objects's handlers
>
to do their thing and return values.
Perhaps. Maybe the 'manager' could be more of an 'introducer'. Creating or
finding references to objects and then passing the appropriate references to the
appropriate objects so they can talk to each other directly.
You'll always need a 'top level' of the hierarchy. I won't call it 'parent'.
Typically, this will be the thing you double-click in the Finder - the one with
the run() handler, but exactly how 'managerial' this object is depends on the
task, and your design approach. It might choreograph, and monitor all
procedures, or it might just store references to the next most significant objects.
I can't say for sure what's the best. This is where the art comes in. :)
>
This "Object Manager" should probably
>
also store (at least some) returned values in properties, so that they don't
>
need to be defined each time that a value is requested.
>
>
Right?
That's what I meant about caching. It allows you to (for example) put all the
hardcoded data in one place, then at runtime, in some kind of initialisation
routine, (or even at compile time), this data gets fished out and cached inside
the properties of the objects where it will be needed. I do this quite often.
>
I understand your point. But my feeling is that, at least for _me_, the fog
>
(which is beginning to clear) seems to come more from the fact that
>
AppleScript is too user-friendly: You can have script objects without
>
explicitly declaring them to be script objects. Seems user-friendly at first,
>
but at some point you're going to have to understand/realize that you *are*
>
using script objects. And that concept is easier to grasp when you
>
specifically declare them as such, thus making them 'visible'.
That's very true. Applescript looks like a procedural language when you first
try it out (recording Finder actions etc.) - little more than a macro editor,
and it comes as some surprise to learn that you are building an object all the
time.
Including an explicit run handler is a good way to remind yourself, or at least
get into the mindset.
--
_____________
Brennan Young
Artist, Composer and Multimedia programmer
mailto:email@hidden
Knowledge is like a circle. Ignorance is the area outside it. With learning, the
circle grows, and the boundary between knowledge and ignorance increases.
The more you know, the more you know you don't know.