Re: solutions to scripting addition terminology conflicts (i.e. the osax namespace problem)
Re: solutions to scripting addition terminology conflicts (i.e. the osax namespace problem)
- Subject: Re: solutions to scripting addition terminology conflicts (i.e. the osax namespace problem)
- From: Simon Forster <email@hidden>
- Date: Tue, 22 Jan 2002 10:49:28 +0000
- Resent-date: Tue, 22 Jan 2002 10:50:12 +0000
- Resent-from: Simon Forster <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: Applescript List <email@hidden>
On Tuesday, January 22, 2002, at 02:54 am, Timothy Bates wrote:
By creating an AppleScript scripting addition as opposed to an
application, what do you gain?
Speed speed speed
How so? The negligible amount of time it takes to launch a small
faceless background application?
This is great because:
a. AppleScript is massively deficient as a language and therefore lots
of
extensions are added.
b. extended code is much easier to read than helper app code when it is
used
frequently...
Unexpected, unexplained coercions are easier to elucidate than an
explicit tell block?
The market sorts this out. People are polite and users get angry if you
redefine existing name space.
Somewhat naive, no? Haven't we seen that this sort of co-operative model
doesn't work very well? All it takes is one person to upset the whole
apple cart.
2) Code becomes more obtuse as funky things are happening on the sly.
Look at the frequent postings we see where some scripting addition or
the other is performing an unseen coercion leading to unexpected
behaviour on different machines.
This is actually an example of how essential extensions are: you are
saying
"these things are used everywhere so they must be bad", I read "these
thing
are used everywhere- they must be very useful"
Not a fair comparison. I'm saying that there should be explicit calls so
that coders can see what's happening rather than hidden coercions making
the code more obtuse and difficult to debug.
It appears that we disagree at a fundamental level here. I think that
protected namespaces and modular code are good things, you like a large
global namespace and things happening with a couple of words. My way you
may type a bit more but you get code that's more robust and easier to
debug. Your way you get shorter code.
Death to scripting additions! Long live faceless background
applications!
No one is implementing basic functionality in this way - it is just too
slow
for language extensions.
I don't want to go here. This involves us agreeing on what should be
defined as basic functionality.
The list of basic things which AS lacks is humungous: regex, math, UI,
file
handling, as long as AS is a light-weight language, the demand for
extensions will remain deafening.
For example, I'm not sure I describe Regular Expressions as basic
functionality but you do. Fair enough.
Maybe the fundamental difference is that I don't see AppleScript as a
programming language per se. It's a neat scripting language which allows
one to do some really neat things quite simply. But at the end of the
day I view AppleScript as digital gaffer tape, not a fully fledged
programming language. Use the tools most suited to the job in hand.
AppleScript for workflow automation and the like; C, C++, Objective C,
Java or whatever for creating applications from scratch.
And yes, AppleScript can be used to create applications. A reasonable
analogy here is using a flat headed screwdriver to undo a cross-head
screw. It can be done but it's not the best tool for the job.
Just a POV.
Simon Forster
________________________________________________
LDML Ltd, 4/5 Hazlitt Mews, London, W14 0JZ, UK
<tel int="+44 20 7602 9370" uk="020 7602 9370">
<fax int="+44 20 7371 6662" uk="020 7371 6662">
<
mailto:email@hidden>
________________________________________________