Re: About the use statement
Re: About the use statement
- Subject: Re: About the use statement
- From: Axel Luttgens <email@hidden>
- Date: Sun, 05 Jun 2016 16:33:04 +0200
> Le 4 juin 2016 à 18:17, has a écrit :
>
> Axel Luttgens 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.
Hello Hamish,
Which "two" are you referring to?
> 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.
Unless…
That’s probably where a better documentation is needed.
The "use" statement is said to be a control statement, the same way the "tell" statement is said to be a control statement; if this is really the intent of the implementors, the "use" statement shouldn’t thus be reduced to an "import" or a namespace specification in other languages: it’s another AS thing again. ;-)
As a control statement, it could be viewed as having the same effect as inserting some kind of implicit "tell" statements according to some rules.
The ASLG tends to imply something along those lines; but clearly, a real definition (not just an analogy based on guesses) would be very welcome…
> 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.
With the "implicit tell analogy", since there is just an "imported event identifier", the above might be equivalent to this one:
tell application "Finder"
reveal someLocalHandler()
end tell
on someLocalHandler()
return application "iTunes"
end someLocalHandler
And indeed, the behavior is seemingly the same.
> 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.)
Again, there is a single "imported event identifier" to care about, so one could be tempted to compare the above to this one:
tell application "Finder"
reveal application "iTunes"
end tell
and observe a seemingly identical behavior.
> 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"!
Yes, that would be an interesting bug. :-)
> 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.
Well, from a certain point of view (the above "implicit tell analogy"), the whole "use" thing appears to be working, without blatant contradictions. In other words, it should be clearly and consistently describable as well.
And I would be delighted to move from guesses/analogies to a definitive description close at hand in the ASLG.
That said, I’m not sure what a good alternative might be.
As far as I understand, you seem to imply that the "use" statement should be implemented as some kind of pure namespace thing. AppleScript, application and library commands would then be put on a same syntactic level and your very first example:
use script "SomeFancySDEFEnabledLibrary"
some fancy command someLocalHandler()
could then probably be made to behave the same way as, say:
get someLocalHandler()
and meet your initial expectation.
But what would the consequences be? A need for additional keywords in the language? Or current language keywords having yet more fluctuating meanings depending on the context in which they appear? Or intractable clashes?
For example, let’s suppose SomeFancySDEFEnabledLibrary has a definition for someLocalHandler, and one wants to invoke that one, instead of the one in the top level script.
Perhaps would it then be needed to write something like:
use script "SomeFancySDEFEnabledLibrary"
some fancy command library someLocalHandler()
so as to make the intent explicit; or, in an attempt to re-use keywords:
use script "SomeFancySDEFEnabledLibrary"
tell script "SomeFancySDEFEnabledLibrary" to some fancy command someLocalHandler()
Of course, in both cases, the benefits of "use" now appear to be vanishing.
Axel
_______________________________________________
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