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: Wed, 10 Dec 2008 19:38:18 -0800
Unfortunately, I don't have time to reply to each of your comments in
detail at the moment. Let me just say that some things work
incidentally rather than intentionally, and it's difficult for a
person examining a script, or a computer compiling/executing a script
(or any program), to determine what's intentional and what isn't if
the original author wrote lots of incidental things into the script.
It's important for authors to make their programs as specific about
their intentions as possible to avoid ambiguity.
(Which is why it's important to design languages, additions, script
libraries, etc. to make it easier to write programs with little
ambiguity and to make it more difficult to write code that does things
incidentally.)
When there are scripts with lots of ambiguity about intention, this
makes it more challenging to change or improve things (the script
itself, scripting additions it uses, etc.) without breaking scripts.
Did the author of the following script intend to open a file using
Finder's permissions and current working directory?
tell application "Finder"
set f to open for access "foo"
set x to read f
-- tell Finder to do something with x, the contents of the file
end tell
Did they intend to consume a file descriptor (which are a limited
resource) in Finder's process? Because that's what that script does.
Now let's say that the author of ‘open for access’ wants to change it
to always open the file within the process running the script instead
of inside Finder, because this is safer, more predictable, and makes
scripts less likely to break in the future if something about Finder
changes that affects this command. The challenge for the addition
author (e.g., me) is that with all the ambiguous scripts around it's
difficult to know which, if any, do this intentionally. Because if
they do this intentionally, changing the behavior as described may
break those scripts.
Similarly, someone working on the script who's aware of this issue may
not be able to tell whether the script was originally written to do
this intentionally or incidentally, so it takes more work to decide
whether it's okay to change the script in a way that would alter where
the command is sent.
Finally, that “someone else” who's working on a script may be the
original author a few months or even years later, when they no longer
recall exactly what they intended the script to do.
Scripts that have incidental, ambiguous behavior are a maintenance
burden for both the script maintainer and the maintainers of
additions, applications and libraries that a script uses. Script
authors, if for no reason other than their own sanity, should attempt
to write scripts that are as intentional as possible, and one way to
do so is to attempt to restrict the commands that are within tell
blocks to those that actually require it.
On Dec 10, 2008, at 12:34 PM, Ed Stockly wrote:
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.
But that's how the technology has been designed and used for all
these years and aside from a few terminology conflicts that crop up
every now and then, it's pretty well worked.
In fact, that's not how the technology was designed (intentional).
That's merely how the technology worked (incidental).
And then Security Update 2008-005, for good reason, broke some scripts
that used some scripting addition commands in certain incidental ways.
And at any time in the future, things that scripts depend upon, such
as additions, scriptable applications and script libraries -- written
by Apple or by others -- may be changed in important and useful ways
that break scripts that only incidentally relied upon certain details
of the old behavior.
To future-proof your scripts, my advice to you is to do as little
incidentally as possible.
Seriously, if it's not broke don't fix it.
Just because something appears to work now doesn't mean it doesn't
have unintended reliance upon things that have never been guaranteed
to remain the same.
Just in case I need to say this: Nobody intends to break compatibility
in any product they make. But the more people there are incidentally
using something a certain way, the more difficult it is to predict
what improvements to that something will break compatibility.
--
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