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, 12 Dec 2008 20:17:18 -0800
On Dec 12, 2008, at 2:16 PM, has wrote:
1. You are proposing that osaxen are treated as individual
namespaces within AppleScript in the same way that applications
already are. This would do three things:
A. avoid polluting AppleScript's globally available terminology
B. avoid osax commands being sent to any process other than the one
running the script
C. break backwards compatibility with all existing scripts that use
osaxen.
... The problem is C: making this change now would be hugely
disruptive to existing AppleScripters and existing AppleScripts.
While osaxen's global nature is an obvious language design flaw and
causes occasional practical problems for users, it's not a
sufficiently serious shortcoming to justify a major break with
backwards compatibility.
...
My own proposal is much more modest and basically an enhancement of
B: don't have processes handle osax commands at all; instead, let
the AppleScript interpreter handle them. OSAX terminology would
remain global within AppleScript and osax commands could continue to
appear inside or outside 'tell' blocks, but they would always be
intercepted and handled by AppleScript. No, it's not a 'perfect'
solution like yours, but AppleScript is not a perfect language (and,
due to its fundamental design limitations, never can be). Instead,
it's a low-cost and almost entirely backwards-compatible
modification whose only goal is to limit the amount of damage that
the current osax loading system can do to the overall OS (c.f. the
recent serious osax-based security hole).
I'm not sure I understand how your proposal is significantly different
from a compatibility standpoint.
The primary compatibility risk is changing AppleScript to handle
addition commands within the sending process instead of the target
process. Many commands may behave differently depending on which
process they are handled in. Now, it may be that 90% of the cases
where addition commands are sent to other processes are incidental
rather than intentional and that the script will work without any
observable change in behavior, but we can't know that that's true of
100% of the scripts. And I am only in a position to be able to make
that determination about the Standard Additions. I can't say what
process dependencies a third-party addition may have.
I should point out that I'm less concerned about outright script
failure than I am about subtle changes in behavior. If a script fails
because an event produces an error, you immediately know that
something went wrong and you can readily determine where in the script
it failed. Because of the nature of some of the commands, changes in
behavior could be subtle enough that scripts don't fail in an obvious
and immediate way. Instead, they may appear to work, but end up
performing partial or no work, or worse: modify or delete the wrong
files, etc.†
So let me ask the list: Do you have any scripts or applications that
intentionally send scripting addition commands to other processes? If
so, why? Does it ever send these events to processes with different
user/group/privileges? Would your script or application behave
differently if it instead sent the addition command to itself?
† Backup regularly, folks!
--
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