|
On 16/01/2015 14:01, Chris Page wrote:
On Dec 18, 2014, at 1:54 PM, has
<email@hidden>
wrote:
Had the author (Chris Page?) of Mavericks AppleScript's new
library loader spent a lot less time being clever and a little
more time actually making it *useful* to users…
[Ears perk up.] Just to be clear: are there any
issues with the library *mechanism* that you would like to see
addressed?
These days I rarely use AppleScript beyond one-liners, so it makes
no difference to me whether AS issues get addressed or not. But
since I make the point and know a bit about the subject, here's a
quick refresh of issues that I've probably mentioned before:
- Your library mechanism breaks 20 years of attachable applications'
assumptions on when they should use a new ComponentInstance vs an
existing one. The library loader shares library objects across the
entire CI, which is appropriate behavior within an ASOC-based
application (where all of the loaded scripts are directly related),
but wrong for regular attachable apps (where the loaded scripts are
completely arbitrary). Even NSAppleScript uses the latter behavior,
which it clearly shouldn't by your own assertion, so at the very
least you should've checked and modified it before 10.9 shipped.
Totally violates Coupling and Cohesion 101, allowing completely
unrelated scripts to interact in all manner of invisible,
unexpected, impossible-to-diagnose ways [1]. The only reason it
hasn't yet caused problems for users is that that there aren't any
libraries available for them to use.
A clean, compatible solution would've been to load and cache
libraries separately for each unrelated script, as the AppleMods
Loader did, then provide an OSASetScriptInfo selector that
special-case clients like ASOC can use to enable per-CI 'global'
caching instead.) But assuming that horse has already bolted, the
least you should have done is:
1. Advise application developers whose apps currently load all user
scripts into the same CI to use separate CIs instead.
2. Modify NSAppleScript to do the same (if you've not already done
so in 10.10).
3. Amend the AS documentation that strongly advises library authors
to make their libraries stateless; that is, not to use properties
for things like "preferences" where client scripts can change the
value of that property at any time.
- All the SDEF terminology nonsense, which 1. makes library
development more complex and laborious for no functional benefit,
and 2. creates all kinds of exciting opportunities for new
terminology conflicts (since clearly the lesson wasn't learnt from
OSAXen). Doubly so when you still don't provide any kind of SDEF
editing or validation tools (something you should've done for
scriptable app developers a decade ago). If you really must use SDEF
format for library documentation (for which it's both excessively
complex and significantly lacking), the least you could do is add an
optional `keyword` flag that allows library authors to disable the
keyword injection crap so they can use it to document normal
identifier-based handlers.
- The `use` keyword; a C&C and keyword injection hell-pit even
I'm afraid to explore.
- The AS documentation should also tell users _never_ to use the
`global` keyword in libraries, as that also trashes namespaces and
invites invisible coupling up the wazoo.
- Oh, and there's also an absolute doozy of an issue in 10.10, where
AppleScript libraries have a .scpt suffix and go in `Script
Libraries` folders, and JXA libraries also have a .scpt suffix and
also go in _the same damn`Script Libraries` folders_. Needless to
say, AS cannot use JS libraries or vice-versa. They can, however,
easily use identical filenames, and no prizes for guessing what
happens then. I suspect this one might be on Other Chris or David
rather than you, but still... wish I could enjoy what you guys
smoke.
And that's just a few obvious *mechanism* issues, of course. I could
say lots more about namespaces, terminology, version management,
search paths, tracebacks and debugging, and so on; but then I'd be
much quicker just writing the damn thing myself.
And, of course, restricting the discussion to *mechanism*
conveniently ignores the AS team's total failure to create or grow
an audience of library users, library creators, online repository
for sharing third-party libraries, or management tools for
efficiently uploading/installing/bundling libraries. Ticking off
"implemented" on some corporate feature list is all well and good,
but even the best-engineered library loader it isn't worth a crap
without any users, libraries, or supporting systems.[2]
For reference, if you think Apple should provide
specific script libraries, please file requests at <Radar>
First, to be blunt, if you don't already know what standard
libraries AppleScript needs then you shouldn't doing the job in the
first place. And if you do already know then you should've already
had it done for 10.9, instead of pissing away weeks of valuable
development time on a library loader that should've been a week's
work at most.
Second, I've seen previous Apple-produced AppleScript code, so let
me counter with a much better offer: I'll assemble half-a-dozen
"standard" AS libraries (not hard as I've done this before), get AS
users to beat on them till they're happy, then Radar it as a
fait-accomplis (i.e. feature request plus code patch) and encourage
other users to file as many dupes as you need. That way, you only
have to allocate time to audit the code and make sure you're happy
with it, and agree to get it into the OS in time for 10.11. (This
approach has a secondary benefit since the libraries can also be
distributed independently, thereby addressing allowing users who
have to support older OSes to use them as well - a known blocker on
library adoption.)
In turn, here are three outstanding tickets [3] that I DO care very
much about, as I do not sleep soundly selling software to customers
while knowing said software lives or dies on the whim of Apple's
legacy/deprecated/broken Carbon APIs:
rdar://problem/19169791
rdar://problem/19169736
rdar://problem/18944184 (duplicate of 14298245)
Code patches already included, so very little technical work
required. While getting these patches into 10.11 won't entirely
remove AS team from my shitlist, at least it'll be going in the
right direction, which is nice.
Regards,
has
[1] Yes, I know there's already some CI-shared state such as TIDs,
but those warts are fixed and well known, whereas there's no end to
the random horrors that stateful libraries may unleash.
[2] Working to build great technology doesn't mean shit, not without
working twice as hard to build influential supporters and mass
audience for it as well. (A lesson Apple taught me the hard way.)
[3] Also filed on OpenRadar (http://openradar.appspot.com) for
benefit of us commoners; just search by ticket number.
|