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).
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!
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…)
|