Re: Tell Blocks Considered Harmful (was Re: open for access)
Re: Tell Blocks Considered Harmful (was Re: open for access)
- Subject: Re: Tell Blocks Considered Harmful (was Re: open for access)
- From: has <email@hidden>
- Date: Fri, 12 Dec 2008 22:16:55 +0000
On 12 Dec 2008, at 13:03, Philip Aker wrote:
On 2008-12-11, at 14:45:47, has wrote:
Well, I think you misinterpreted my lousy illustration :-). It was
intended to show how "terminology providers" will be an upgrade to
'tell application "XXX"' not how to upgrade the existing facility.
It's not clear what you mean by 'terminology providers',
You can review the concept starting at <http://lists.apple.com/archives/applescript-users/2008/Dec/msg00037.html
>.
Did look for earlier posts but missed that one. Comments on it:
'Provider' is a better choice of phrase than 'terminology provider'
inasmuch as the latter is actively misleading. The terminology
retrieval aspect is merely an implementation detail - a workaround for
Apple events' use of cryptic four-char-codes instead of human-readable
strings as symbols. The major goal of any import mechanism is to
provide programs with access to additional functionality.
'Functionality provider' would be a better choice that 'provider' in
that at least it gives some clue as to what is being provided.
However, none of these terms are a good choice for a language like
AppleScript whose target market is primarily made up of non-
programmers. The reason AppleScript uses the word 'application', for
example, is that its meaning is immediately obvious to any Mac user,
regardless of whether or not they've any existing programming
knowledge. Introducing abstract jargon makes the language less
penetrable, and therefore less appealing, to those not already
familiar with it.
It's been established that the concept is understood by the person
to whom it was meant to be communicated.
It's also assumed that if you're posting on a public forum that
additional feedback is acceptable or even actively sought. (Whether or
not it's what you'd like to hear is another question, of course.:)
I'm not sure a further explanation would serve any purpose since
you've waxed on at length about a concept you're not clear on but
somehow ideologically opposed to.
I think I understand it well enough. As far as I can tell, you are
actually proposing several things:
1. You are proposing that osaxen are treated as individual namespaces
within AppleScript in the same way that applications already are. This
would do three things:
A. avoid polluting AppleScript's globally available terminology
B. avoid osax commands being sent to any process other than the one
running the script
C. break backwards compatibility with all existing scripts that use
osaxen.
Yes, A and B would be nice; indeed, it should have been done this way
from the start. The problem is C: making this change now would be
hugely disruptive to existing AppleScripters and existing
AppleScripts. While osaxen's global nature is an obvious language
design flaw and causes occasional practical problems for users, it's
not a sufficiently serious shortcoming to justify a major break with
backwards compatibility.
My own proposal is much more modest and basically an enhancement of B:
don't have processes handle osax commands at all; instead, let the
AppleScript interpreter handle them. OSAX terminology would remain
global within AppleScript and osax commands could continue to appear
inside or outside 'tell' blocks, but they would always be intercepted
and handled by AppleScript. No, it's not a 'perfect' solution like
yours, but AppleScript is not a perfect language (and, due to its
fundamental design limitations, never can be). Instead, it's a low-
cost and almost entirely backwards-compatible modification whose only
goal is to limit the amount of damage that the current osax loading
system can do to the overall OS (c.f. the recent serious osax-based
security hole).
2. You are proposing that an extensible mechanism for connecting to
different types of resources (applications, osaxen, frameworks, etc)
is added to AppleScript.
As pointed out before, this would be fairly pointless in practice:
such a general purpose extension mechanism would need to interact
extensively with AppleScript's innards (compare with the Python and
Ruby public C APIs, for example). AppleScript does not provide a
public C API for interacting with its innards, which means that the
only people in a position to create new classes of connectors are the
AppleScript engineers, making it quicker and cheaper for Apple to
implement any additional connectors directly within AppleScript on an
as-needed basis. Meanwhile, third-party developers can continue to
expose functionality via existing mechanisms, i.e. scriptable
applications/FBAs and osaxen, which are also quick, cheap and familiar
solutions.
3. You are proposing that scripts target all classes of connectors
using the same one-size-fits-all interface.
This part of your proposal has actually gotten worse since your
initial post. Originally you suggested only that 'application
"NAME"'/'application id "BUNDLE-ID"' specifiers be replaced by a
'provider "BUNDLE-ID"' specifier. That would make AppleScript code
less descriptive and harder for readers not already familiar with the
language to understand. Subsequent revisions also add two brand new
language structures, increasing language complexity:
A. a new 'associate' declaration somewhat similar to the existing
'property' declaration
B. immutable variables*
(* Allowing scripts to rebind 'associated' variable names - e.g.
'fndr', 'stadds' - would mean that a tell block's commands would be
compiled against a specific provider but could be sent to any other
object at runtime. Therefore, 'associated' variable names must be non-
rebindable to avoid confusing users or creating new opportunities for
runtime errors to occur.)
You're also implying that an extra layer of indirection be added
between identifying a provider and using it, so that instead of writing:
tell PROVIDER ...
users now write:
associate PROVIDER_NAME with PROVIDER
(* a bunch of other code in here *)
tell PROVIDER_NAME ...
You compare this approach to the approach used by Python, Perl, etc.
to import and use modules. However, those languages require a greater
degree of prior knowledge and abstract thinking to understand and use
such features effectively; one of the reasons they have a higher
barrier to entry than AppleScript. AppleScript's 'tell application
"NAME" ...' syntax is simple, self-explanatory and non-abstract as it
can be - important advantages over those other languages given that
AppleScript's main audience often has limited prior knowledge and
little or no ability to deal with abstractions.
...
To summarise:
- You are proposing significant/major changes to the language.
- These changes involve significant/major development costs.
- These changes involve significant/major disruption to existing users.
- These changes make the language less attractive to non-programmers
(its major audience and raison-d'être).
- These changes still won't make the language any more attractive to
professional programmers.
- Concrete benefits (as opposed to theoretical ones) will be
measurable somewhere between modest and minimal, and far outweighed by
the above costs.
In other words, making grand sweeping changes to AppleScript is wasted
effort - lots of hard work and upheaval that'll mostly just honk off
existing users without making their lives noticeably better.
If you can afford a major investment, you'll get a better return for
your money by creating a brand new language, one that can build on all
of the advances that have been made in end-user programming research
in the last fifteen years and isn't hamstrung by the inherent
limitations of the current AppleScript design.
If you can afford a more minor investment, you'll get a better return
from minimally disruptive changes that iron out the most egregious
flaws in the current system (e.g. those affecting security or
reliability) and provide small, well-targeted benefits (e.g. better
text handling commands, better interpreter performance) that appeal to
the majority of users.
I'm not trying to be mean for the sake of it, but any modifications to
the current AppleScript implementation need to take into account the
needs and abilities of the language's target audience, and the
fundamental limitations of the existing language design.
Alternatively, if you really do require a deep, sophisticated,
unrestricted language API, there is no shortage of languages that
cater to such needs and you'll be far better (and happier) using one
of those instead rather than trying to turn AppleScript into something
it isn't supposed to be.
Regards,
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
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