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: Timothy Bates <email@hidden>
- Date: Tue, 22 Jan 2002 13:54:59 +1100
On 21/1/02 9:36 PM, "Simon Forster" <email@hidden> wrote:
>
On Monday, January 21, 2002, at 09:02 am, Neal A. Crocker wrote:
>
> I propose three alternative solutions to the problem of scripting
>
> addition terminology conflicts.
>
Which presupposes that scripting additions are a good thing.
Horse for courses
>
By creating an AppleScript scripting addition as opposed to an
>
application, what do you gain?
Speed speed speed
>
Scripting additions extend AppleScript's
>
language which, from this naive users perspective, means that coercions
>
happen auto-magically so I don't need to use explicit tell blocks.
>
That's about it. Is this a good thing? I'd answer no.
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.
If I occasionally add a tell finder block, that is one thing, but if I had
to wrap every call to existing extensions in a tell block the code would
double in length and triple in reading-complexity.
I think the average AppleScript user has no ideas just how much of
AppleScript is actually extensions to AppleScript.
>
1) There's only one global namespace so we start getting naming
>
conflicts if everything's written as a scripting addition.
The market sorts this out. People are polite and users get angry if you
redefine existing name space.
>
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"
>
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.
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.
Itim