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: Fri, 19 Dec 2008 02:59:39 -0800
On Dec 18, 2008, at 6:14 PM, Shane Stanley wrote:
On 18/12/08 4:19 PM, "Chris Page" <email@hidden> wrote:
My definition of “work” is that it works in as many situations as
possible and is not likely to break when I run it on another
computer or after a software update, and that I never have to
change it.
So you never script Finder, System Events, Mail or in AppleScript
Studio.
I'm saying you should only put commands inside tell blocks when they
need that application's terminology and you intend to send those
commands to the target application.
When you put ‘open for access’ in a ‘tell application’ block, you're
sending that command to the target application. The target application
then opens that file, potentially with different results than if you
handled that command in your script.
Tell blocks are meant to be a convenient way to avoid putting
‘tell ... to ...’ on every line. But you should avoid putting commands
inside them that aren't a part of that application's terminology. You
should avoid putting commands inside a tell block if you wouldn't put
a ‘tell ... to ...’ in front of that line.
Scripts are more likely to continue working in more situations and in
the future if you are judicious about tell blocks and avoid wrapping
large swaths of code in them. And if increased reliability isn't
enough of an inducement: by avoiding unnecessarily sending Apple
Events to other programs, your scripts will run faster.
In fact, by your definition of work, anyone who uses the Finder
rather than do shell script to do file management is not writing
"working" scripts, given the combination of Finder scripting's
dreadful history, combined with what's happened with almost every
other app that's gone from Carbon to Cocoa. (And yes, by and large
that's what I'm doing with the Finder myself.)
That's not at all what I'm saying about Finder. Playing off your
example, what I'm really saying is: Don't send ‘do shell script’ to
Finder. Only send Finder commands to Finder.
Though, it does illustrate my point about better support for
libraries. There should be a file manipulation library you can use
without involving any applications or additions. Scripting
applications should be for higher-level operations, like constructing
a document.
The truth is that scripters live in an uncertain world. We're at the
mercy of OS programmers, app programmers, and often product
management types who'd just love us to disappear and remove one more
development cost. We can worry about how long our scripts will last,
and possibly drive ourselves to the grave before they break, or
solve today's problems today.
I'm offering some suggestions for how to write scripts with fewer
interdependencies, to help reduce the uncertainty. When you send ‘open
for access’ to another application, you're open to a much higher risk
of that command breaking your script at some point. If you handle that
command in your script, you are only dependent upon the scripting
addition. You reduce your risk of breakage. You reduce your dependency
on the complex interactions of additions and applications.
Great. But you're also asking about a fundamental change in behavior
that will guarantee that people's scripts will fail in more
situations.
I'm asking: What changes can we make without breaking your scripts?
I'm all for change -- but only for the better, not for its own sake.
It's better if you use tell blocks judiciously than not.
One of the reasons lots of people had scripts that kept working for
revision after revision of the OS was, ironically, because for a
long time AppleScript didn't change much.
One reason AppleScript and Standard Additions haven't changed much is
because it's difficult to change them without breaking scripts, or
because we can't anticipate whether and how certain changes would
break scripts, so we're conservative and leave them unchanged even
when we could have provided some important improvements.
To improve AppleScript, additions and applications, we and third
parties need scripts to be specific about their intent and not throw
everything into tell blocks, which make it harder for us to anticipate
exactly what unintended interactions the script requires to work
correctly.
It's unfortunate that certain fundamental features of AppleScript put
us in this position, but it's where we are, and I'm just offering some
suggestions for how you can write better scripts that are less likely
to break and which make it easier for us to improve things without
unintentionally breaking them.
OK, but I think you've received a pretty comprehensive answer from
people here, which can be summarised as: for dialogs, they often aim
them at apps to stop the user from making changes, and with other
scripting addition commands they do it for perceived convenience.
If you're puzzled that I'm repeating myself, it's because this is a
very long thread with a lot of participants and topics, and I'm trying
to make sure I explain myself each time the same point comes up
without requiring everyone to have read all the other messages.
This is an ongoing conversation about a number of issues.
--
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