Re: Library Use Statement Question
Re: Library Use Statement Question
- Subject: Re: Library Use Statement Question
- From: Deivy Petrescu <email@hidden>
- Date: Tue, 24 May 2016 07:57:38 -0400
> On May 24, 2016, at 07:22 , has <email@hidden> wrote:
>
> Deivy Petrescu <email@hidden> wrote:
>>> > On May 20, 2016, at 22:07 , Shane Stanley <email@hidden>
>>> wrote:
>>>
>>> >
>>> > On 21 May 2016, at 10:07 AM, Deivy Petrescu <email@hidden>
>>> wrote:
>>>
>>>> >>
>>>> >>
>>>> I thought you could call any handler of a library included in the script.
>>>>
>>> >
>>> >
>>> Libraries aren't "included" in the script, though -- they're a potentially shared resource. And although it might be considered more convenient to have stuff loaded automatically, that's the sort of convenience that got us into the mess with scripting addition namespaces we suffer with.
>>>
>>> >
>>> >
>>> --
>>>
>>> > Shane Stanley <email@hidden>
>>> > <www.macosxautomation.com/applescript/apps/
>>> >
>>>
>> "Libraries aren't "included" in the script, “
>> Shane, I understand that, however, I don’t know what would be the appropriate terminally, “used”, “called”, “loaded" ?
>>
>> I particularly disagree with loaded, which was the old terminology and it really meant loading the “library” into the script.
>>
>
> The technical term would be "import", but "load" is also okay.[1] A library script is dynamically loaded[2] via OSALoadFile() when a `script "NAME"` expression is evaluated, then hosted within an AS component instance as a script object instance that persists for the lifetime of that CI. AS then dispatches messages from your own script to the library script much as it dispatches them within your own script (i.e. message parameters and return values are passed as-is, not copied as they are in OSAX/scriptable app commands).
Import is good. However, thinking of Python, I don’t really know what happens when you " from @ import * “. I mean, I know I get the namespace of @ and I know that this is done at runtime, but I am not sure. I se it and I know it works.
As for load, unless I am mistaken, load script file would actually load the whole “library" into the calling script, that is taking actual disk space. I don’t think this happens with the libraries. That is mi issue with loads
>
> If the library has a dictionary then the `use` statement also adds those event codes to the AS interpreter's global message dispatch tables so that messages that your script dispatches to itself will be automatically redirected to the library as appropriate, without the need for an explicit `tell script "NAME"` block. (It's the same mechanism that allows an OSA-attached script to send messages to the host application without needing to target it explicitly with a `tell application "NAME"` block.)
(*)
>
> That's obviously what causes users' confusion, because even though `some message x with y` and `someMessage(x, y)` are the technically and conceptually the same thing - i.e. message sends - the AS runtime does some extra magic when dispatching the terminology-based command to determine its intended target that it never does with the identifier-based command. To illustrate, here's some normal and pathological examples to chew on (and I shudder to think how many thousands of hours it's taken me to figure out exactly how AS operates internally for myself):
>
> tell app "TextEdit" to set documentRef to document 1 -- get a 'reference' value for use in subsequent commands
>
> closeDocument(documentRef) -- dispatches `closeDocument` message to local script, as you'd expect
>
> tell script "SomeLib" to closeDocument(documentRef) -- dispatches `closeDocument` message to script library, as you'd expect
>
>
> close documentRef -- dispatches `coreclos` message to TextEdit, not local script, even though it's not in an explicit `tell` block!
>
>
> use script "AnotherLib" -- import a terminology-based library that defines an `another library command` handler
> another library command documentRef -- dispatches `ALibCmnd` message to TextEdit, not to script library as you'd expect!
Does this contradict your statement (*) above? I thought the another library command documentRef would send a message to the library, as (*) indicates.
May be I misunderstood something.
>
>
> Basically, the whole "AppleScript is this friendly English-like language" thing's a huge fragile house of cards, cunningly crafted by programmers so busy being ingeniously clever in their use of smoke and mirrors they've never stopped to ask themselves if they aren't just digging their users into a hole with all this dishonesty. The problem with telling lies, even well intended white ones, is that you end up having to tell more and more lies to keep the previous lies afloat that eventually nobody can keep track of all the obfuscations and fiddling, and ultimately it all blows completely apart on both liars and lied-to. In the meantime, it's just the slow torture of a thousand cuts, where things seems to work but only up to a point, and then users are screwed because they've no clue what it's doing or why it's doing it.
>
>
> This is why I've been saying for years that if Apple is serious about End-User Programming then it should start over from scratch and design and build a whole new language that draws lessons on what to do (and what NOT to do!) from Logo, AppleScript, and several decades-worth of UX/UI learning and experience.[3] There's huge untapped potential here to revolutionize Human-Computer Interaction here, and not just in a way that serves the great unwashed minority of natural-born computer nerds whose idea of productivity is debugging 500KLOC lines of Java braindeath, or even the small but perfectly formed posse of DTP geeks who accidentally stumbled into this odd little AppleScript language that nobody else in the world can make sense of. (Not that folks here understand AS either, mind; they've just picked up enough voodoo incantations to make it do mostly what they want.)
>
> Alternatively, Apple should just adopt an existing scripting language like JavaScript, which may stink at usability but has a large established customer and vendor base to provide the tools, documentation, education and support to enable most users to get by on it (aka "Worse is Better"). Alas, since Apple will neither admit it doesn't give a crap about EUP nor that it's already FUBARed JavaScript as an alternative to AS, we're pretty much stuck with one crappy language that's moribund and another crappy option that's DOA, and meantime the notion that users should be able to control their own tools as they wish instead of only using them as Apple/Google/etc dictate is relegated to the unfashionable hardcore nerd contingent who don't even use their machines as the rest of the world does. It's all very disempowering and disappointing from a User POV, although inevitably unsurprising as despite its "cool" and "user-focused" image Apple is just as ineptly bureaucratic and rigorously self-serving as any other large corporate organization.
>
>
> Regards,
>
> has
>
> [1] "Include" would be wrong, however, as that basically means merging source code from all files into one big ball of mud and then compiling that. I think SD's old library system did this too, and C does it via its `#include "NAME" macro` (technically it merges all the header files first then merges the code files after compiling each one individually but the result is the same).
>
> [2] The caveat is that the dictionary support relies on the AS compiler having access to the library's terminology in order to compile your script, so there's some compile-time coupling as well, thus you can't compile a `script "NAME"` expression unless a library by that name already exists.
>
> [3] Personally I'd love to have a few free months to get back onto my skunkworks project to create a Logo/AppleScript hybrid that attempts to nail these problems. The first draft's about half-done and has been since the start of the year, but it's not in a fit state to release yet. But it would allow users to write scripts in pidgin English, with fairly intuitive white space and punctuation rules (without the need for terminology dictionaries or other brittle, inconsistent magical crap), that gives most of the friendly appearance and readability of AS code with most of the simplicity, clarity, and ease of learning of Logo. (Alas, the mounting need to put food on table must come first; maybe once I've finished conquering the packaging artwork automation field…)
>
About [3], if I am not busy, count my in as a guinea pig.
Deivy Petrescu
email@hidden
_______________________________________________
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