Re: solutions to scripting addition terminology confilicts
Re: solutions to scripting addition terminology confilicts
- Subject: Re: solutions to scripting addition terminology confilicts
- From: has <email@hidden>
- Date: Sun, 27 Jan 2002 00:31:53 +0000
Neal A. Crocker wrote:
>
2) Scott Nortons's idea of making "modular" use of osax by separating
>
their terminology from their code:
Scott's hack is quite ingenious and I doff my cap alongside everyone else,
but ultimately it's a non-standard, unofficial hack - meaning it's a world
away from being a viable 'real world' solution, IMHO.
Any fundamental change to the way osaxen work needs to come from Apple
itself. Where they lead, everyone will follow. Otherwise - well, I know I
wouldn't want to be the one who keeps explaining to newbies that... well,
actually, they have to do things a different way, that's... no, not
described in any of the official literature and... no, isn't officially
supported by Apple and... well, probably isn't being used by many other
scripters anyhow. No thanks...
I'm aware this is raining on folks' parade somewhat. But, seriously, say
you take a look at the current community support for - and use of -
AS-based mods/libraries by way of comparison.
"What support?" I hear you cry. Well, exactly. AS must have the poorest mod
support of any commonly-used scripting language. Why? Because the language
itself doesn't give it the first class support it needs to make it
successful. Examples:
1. The folks who do bother to use mods can't even decide which part of the
system they should be stored in. Scripts folder? Scripting Additions
folder? Where?
2. There's no built-in mechanism for loading mods into user scripts at
runtime.
Sure, a determined scripter can roll their own mod-loading code, but this
is a non-trivial task (see 2), made even harder since there's no consensus
on where modules should be stored in the first place (see 1 again).
So a valuable tool, used heavily in any other language worth its salt, is
left languishing on the sidelines whilst AS scripters far and wide
individually reinvent the same old wheels over and over again.
And that's with completely standard code used in a completely normal
fashion. So what chance would some unofficial, non-Apple sanctioned
low-level hack cooked up by some bunch of scripters that most ASers
probably haven't even heard of stand of making it into the next edition of
AppleScript in a Nutshell? Sorry, but IMMHO it'd just be a recipe for
another shambles.
[suggestion for a 3rd-party scheme]
>
Given these drawbacks, I propose an alternative, somewhat similar,
>
scripting "module" scheme that would require some work by an
>
adventurous, community-minded osax developer (should I volunteer my
>
own novice services?):
Sorry, but I'm going to be a wretch and shoot at this as well. In addition
to punting it with the above argument [no hacks], I'd point out that the
proper approach, not to say syntax, should be:
tell module "Standard Additions"
set x to ASCII character 1
end tell
The above would have to come from Apple, of course. Anything else is just a
stinky syntactically-confused hack. This "load/unload/using terms from"
stuff doesn't sound like good [language] design to me. It's depressing
enough that AS's "using terms from" construct is necessary in the first
place (I'd be surprised if any other language has such a thing), without it
being used and abused in order to prop up flaws in an unrelated system as
well.
Lastly, avoid any "you-only-have-to-use-it-if-you-really-want-to" stuff as
well, because that would simply be another disaster waiting to hit critical
nuisance mass.
A new modules system must use a consistent, logical syntax; i.e. a tell
block. Inclusion of that tell block must be compulsory. And the new system
should exist independently of the existing scripting additions system.
Anything else is just compounding the mess.
With the release of this new system, the Scripting Additions system would
be deprecated. No further osax development should take place beyond this
point. Then, after a suitable transition period, the SA system should be
disposed of for good.
If the new system were to support existing osaxen with little or no
modification, that'd be great. (And if it also supported AS-based mods,
that'd be even greater.:) But these must be secondary considerations to
just doing it right in the first place.
[summary]
If you can't straighten out the current system by getting developers to
stay out of each others' keywords, then it's time to bite the bullet and
replace it with something decent. Band-aid hacks and patches aren't good
for a language - or for its users, both present and future. Fundamental
change requires fundamental support, however, and that means Apple has to
be the one to do it.
So if folks really are serious about it, start drawing up petitions and
lobby Apple [and the AppleScript team] like mad. And get them to change it
*now*, when it will cause relatively little disruption, and not later, when
it'll cause more chaos than it solves.
Otherwise this has all been empty talk and a depressing waste of good
energy that'd be better expended elsewhere.
Regards,
has