Re: Scope of globals, parents and children, "load script" an
Re: Scope of globals, parents and children, "load script" an
- Subject: Re: Scope of globals, parents and children, "load script" an
- From: Sander Tekelenburg <email@hidden>
- Date: Tue, 22 May 2001 18:19:47 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 21:09 -0400 UTC, on 21/05/2001, email@hidden wrote:
>
On Sun, 20 May 2001 04:32:42 +0200,
>
Sander Tekelenburg <email@hidden> asked,
[...]
[globals]
>
We need to be very careful about the words "declared" and "defined."
Yes. _That_ difference is quite clear to me :) When I talk about "declaring"
I mean declaring a variable to be a global. I'm not talking about assigning
it a value.
[...]
>
Also note that the reply ("You don't need the original declarations any
>
more") was predicated on rewriting the script to use script objects.
Ah OK. I had misunderstood that then. Thanks.
[Transforming all-in-one script to a group of script objects]
>
The map for that transformation is like this:
>
>
Procedural ("structured programming") script:
[...]
>
Object-oriented script
[...]
Very clear. Thanks!
I think what I need to do boils down to this then:
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". That way, even _if_ a 'need' for globals
remains, they would only have to be global within the relevant script object.
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. 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?
[...]
>
> How would a variable name ever be used without my knowing? I am the
>
> author. I decide how to name my variables. I make it a point to never use
>
> the same name for a variable within 1 script.
>
>
And how did my keys end up on the kitchen table this morning? I make it a
>
point to put them on the hall table. ;-)
Good point :)
>
The challenge of writing a complicated script is to manage the complexity
Yep :)
[...]
>
Mac users will probably best understand globals by looking at their
>
individual Mac desktop. How many files can you keep there before it gets
>
out of control? Globals certainly work; the problem is that beyond a
>
certain point, this
>
unstructured, unorganized pile of data makes for scripts that are difficult
>
to write and much more difficult to understand six months later.
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'.
(This 'too user-friendly problem' is similar to being able to double-click
files in the Finder and have them opened in the 'appropriate' application.
Nice, until you don't have the 'appropriate' application, or want the file
opened in another application. All of a sudden the user needs to learn that
applications have an "Open" command and how to use the "Open file" dialog.
Not hard in itself, but confusing if up until then your Mac always read your
mind ;))
[...]
>
> In general I try to not use globals too easily. But in this script, some
>
> things are referred to over and over again; both in several handlers and
>
> within the main script. I doubt I can get rid of all globals _and_ keep
>
> the whole thing comprehensible...
>
>
Put the "several handlers" and the globals they access in a script object.
>
Then access any data you need to from the main script by using "varname of
>
scriptname".
Yep. Clear.
>
A further refinement would be to avoid accessing the properties of the
>
script object directly, particularly if they don't naturally represent
>
things you should meddle with. That is, if a script object contains a list
>
of tasks to do, accessing the list of tasks itself is letting too much of
>
the details of the way the list is put together leak out of the script
>
object. Its better to have a handler that adds a task to the list, one
>
that removes a task, one that finds a task, and one that executes a task,
>
than to go in and manipulate the list from outside the script object. [...]
Not 100% clear to me yet. But I think I should just start working on this
now. Then it probably will become clear. (If not, you'll hear from me again
;))
[...]
>
The way to work with a complex thing is to break it into a simple
>
arrangement of simpler things.
That's what I always tell my students ;) But this:
>
That's what script objects are
I hadn't realised until now.
Thanks!
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <
http://www.pgp.com>
iQA/AwUBOwqRnesywKfXgqKdEQJ/LACg/MvVreLyZdvCQCJfOQzrUi5KKmIAn0bi
f6+8KuTSNEMazDHCk9/3eHd/
=B+zD
-----END PGP SIGNATURE-----
--
Sander Tekelenburg, <
http://www.euronet.nl/~tekelenb/>
Mac user: "Macs only have 40 viruses, tops!"
PC user: "SEE! Not even the virus writers support Macs!"