On Dec 10, 2008, at 1:46 AM, Philip Aker wrote:
On 2008-12-09, at 18:25:18, Chris Page wrote:
i.e., even with “associate … with” it would be best to avoid placing things inside tell blocks unnecessarily.
Ok and yes, but my intent is to solve AppleScript's symbol addressing problem such that calls to other terminology providers within a 'tell application' block can be made unambiguously. What I'm trying to illustrate is an upgrade to 'tell application "XXX"' such that the terminology association and interpretation is associated to the bundle id rather than the application name (tell bundle id "XXX"). This would allow suitable code hunks such as osaxen to participate. Perhaps it would be too much to have to bind terminology providers at the top level of a script (as you are doing above) however it would bring a certain amount of clarity to the language. It's the norm in other languages such as Perl, Python, Ruby, and Tcl to use import-like calls at the top level of their scripts.
Yes, I understood what you were suggesting, and I agree something along these lines is a good idea. But not using tell blocks. Instead, for example, you could “import” the term ‘open for access’ and then use it without any tell blocks, and the command would always be sent to the scripting addition within the current process. Nesting tells is going to continue to be a problem unless you somehow change its behavior to eliminate ambiguities.
Binding identifiers as above would imply a URI (somewhat similar to XML namespaces) with the default items being the pre-loaded providers on the local machine. With an eye to even greater usefulness sometime in the future (e.g. iPhone), it might be possible to devise a load-and-bind form:
That's interesting, though it would have to require user interaction to authorize, since it's loading executable code from across the Internet. Would it still be useful if it required interactive authentication to run that script?
From a security perspective, I think we might be better off requiring people to download and install that OSAX as they do today.