Re: About the use statement
Re: About the use statement
- Subject: Re: About the use statement
- From: has <email@hidden>
- Date: Sat, 04 Jun 2016 17:17:46 +0100
Axel Luttgens <email@hidden> wrote:
>Le 4 juin 2016 à 02:26, Shane Stanley a écrit :
>
>[…]
>
>So all those who are confused, angry or frustrated — or even mildly surprised -- put up your hands.
As usual, the ASLG provides some clues, yet somewhat too elliptically.
Perhaps could the whole "[FYI] more sdef-based library stupidity" thread be viewed as the basis for a documentation enhancement request?
At:
https://developer.apple.com/library/mac/documentation/AppleScript/Conceptual/AppleScriptLangGuide/reference/ASLR_control_statements.html#//apple_ref/doc/uid/TP40000983-CH6g-SW4
one may read:
use statements can also import terminology from the used
resource, making the terms available throughout the script
without requiring the use of tell or using terms from.
AppleScript tracks where terms were imported from, and sends
events that use those terms to that target. Ordinarily,
commands are sent to the current target (it) as described in
Target, but imported terminology overrides this. If…
• the event identifier is imported
• the direct parameter is an imported class or
enumeration identifier
• the direct parameter is an object specifier ending
with an imported term
…then the command is sent to the import source instead. This
happens even if the command is inside a tell block for a
different target.
It is rather difficult to tell, from the above, the exact decision tree (does one of the conditions prevail? does the description imply some ordering? is the description a complete one?).
The two are completely orthogonal. The ASLG text above explains how an
imported keyword command is dispatched. It has nothing to do with how
the command parameters are evaluated, because those are standard AS
expressions and thus should evaluate according to standard AS expression
rules. In fact, the above description of how keyword-based commands are
dispatched is actually violated by the current parameter evaluation
behavior, because what AS should be doing is evaluating the direct
parameter expression first, then dispatching the keyword command to the
app/script object returned by that (if any). For example:
use application "Finder"
reveal someLocalHandler()
on someLocalHandler()
return application "iTunes"
end someLocalHandler
Here the direct parameter should evaluate to an application object for
iTunes, so according to AS dispatch rules the `reveal` command should be
sent to that. Which it does, if I write:
use application "Finder"
reveal application "iTunes"
(The fact that iTunes may or may not understand the `reveal` message is
irrelevant here. It's AppleScript's job to do just what you tell it to
do, not to invent its own ways of doing things as goes along.) It's no
different to writing:
log 2 + 2
and getting "4", and then translating it to:
log f()
to f()
2 + 2
end
and getting "Chicken"!
And as to the idea of making this a "feature" via documentation
enhancement request: YOU CAN'T! Not because is it straight-up psychotic
(although it certainly is that), but because it's a perfect logical
contradiction:
YOU CAN'T SEND THE COMMAND TO THE OBJECT GIVEN AS ITS DIRECT PARAMETER
IF THE VERY ACT OF OBTAINING THAT OBJECT FOR THE COMMAND CHANGES THE
OBJECT IT'S GIVEN!
Oy. Russell's Paradox surrenders.
has
_______________________________________________
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