Re: Tell Blocks Considered Harmful (was Re: open for access)
Re: Tell Blocks Considered Harmful (was Re: open for access)
- Subject: Re: Tell Blocks Considered Harmful (was Re: open for access)
- From: Chris Page <email@hidden>
- Date: Tue, 09 Dec 2008 18:18:12 -0800
On Dec 3, 2008, at 6:05 AM, Bill Cheeseman wrote:
on 2008-12-02 11:51 PM, Chris Page at email@hidden wrote:
Although judicious use of tell blocks to address specific objects
can make code clearer when you're performing several consecutive
operations on the same object...
...
tell application "Finder"
tell window 1
-- multiple statements affecting Finder window 1
end tell
end tell
Yes, that’s the sort of thing I was referring to, above. The main
thing is to keep tell blocks small and to not put extraneous commands
inside them, especially scripting addition commands, which are a
maintenance issue because they can collide with future changes to
application terminology.
It can also be a problem for someone examining or editing a script
(even the original author) to tell whether a command is being sent to
another process on purpose. It’s more difficult for them to tell how
the script was intended to behave if tell blocks aren’t used
judiciously.
But you are saying that this snippet is NOT OK, at least in principle:
tell application "TextEdit"
tell application "Finder"
tell window 1
-- multiple statements affecting Finder window 1
end tell
end tell
end tell
Right?
Yes, that’s one example of undesirable tell block use. In that
particular case, nested “tell application” blocks make it confusing
which application is providing which terminology and handling which
commands. One really should never nest “tell application”, because at
best the inner “tell application” overrides the outer one, rendering
it pointless. Nested tell blocks should be reserved for referring to
objects within a given application.
The general case is wrapping most or all of a script within a “tell
application” block when most of the script doesn’t use that
application’s terminology or explicitly mention any of that
application’s objects with specifiers. I think what happens is people
think “I’m scripting Finder” and so they just start with ‘tell app
“Finder”’ and write their entire script without paying much attention
to which parts of their script actually involve Finder.
I recently ran into a script with several dozen lines of code wrapped
in ‘tell app “System Events”’ in which only the very first line--a
“path to” command--needed a tell at all.
It might not be a bad idea for the AppleScript compiler to perform
some optimization of tell blocks (assuming such a thing is possible).
When you compile a script it could be changed to reduce the size of
tell blocks to only surround blocks of code that actually need them,
and isolated lines of code could be changed to use tell statements.
Another thing that might be useful is to issue a compile-time warning
(or perhaps even an error) if there are nested “tell application”s.
Another reason to avoid throwing lots of commands into tell blocks is
because the implementors of scripting additions (e.g., me) can’t tell
whether you’re intentionally sending the commands to another process
or if it’s an accident of how the script was written. For many
commands this can be an important concern because the semantics--the
meaning--of performing a command in one process versus another may be
significantly different.
For example, “open for access” opens a file and creates a Unix file
descriptor in the process running the command. The interpretation of
file paths, permissions and the limit on the number of open files all
depend on the process performing the command. Whether or not the
command succeeds or the script works as intended depends on which
process it sends the command to. If a script unintentionally sends
“open for access” to other processes, it may work today, but in the
future it may not.
Perhaps worse, when there are lots of scripts unnecessarily sending
commands to other processes, the implementor of a scripting addition
can’t know whether it’s safe to alter the command in ways that might
not be compatible. For example, let’s say I wanted to change “open for
access” to operate with the permissions and current working directory
of the sending process instead. I can’t really know whether someone
out there is sending this command to another process to intentionally
use that other process’s state. Someone might, for example, tell
another process to open a file so that the file remains open across
multiple runs of the script--a very, very bad idea, but someone may
rely upon it.
If script authors keep tell blocks to a minimum, that makes it easier
to tell what’s intentional and what’s not, for people using or editing
scripts and for implementors of scripting commands.
--
Chris Page
The other, other AppleScript Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden