Re: Migrating scripting additions to Mac OS X
Re: Migrating scripting additions to Mac OS X
- Subject: Re: Migrating scripting additions to Mac OS X
- From: Shane Stanley <email@hidden>
- Date: Wed, 27 Jun 2001 09:00:31 +1000
On 26/6/01 10:29 PM +1000, JollyRoger, email@hidden, wrote:
>
> But URL Access is nothing like a lot of scripting additions -- it has never
>
> even _been_ a scripting addition. I don't see the relevance.
>
>
The relevance is that it's perfectly useful even though it's not a scripting
>
addition. Why ignore that fact?
I'm not ignoring it -- I'm just suggesting it's irrelevant to, say, Jon's
Commands.
>
>
I don't see how it makes AppleScript any harder to learn. Can you give me
>
more details?
The more nesting of tells you have, the harder code gets to read.
>
>
> Why, for example, put ReGex in an app? Or Jon's Commands? Or
>
> StuffIt Commands, or XML Tools, or the various text utilities?
>
>
Why *not* put them in apps??
Because there's no need -- they work fine like they are. The whole point of
StuffIt Commands was to make the use of an app unnecessary -- and the
resulting speed-up for scripts is enormous. That's why Leonard wrote it!
>
>
> It's crazy -- you're trying to throw the baby out with the bath water.
>
>
I don't see anything crazy about it. I've seen it work just fine, on the
>
contrary. I'm in the process of converting three or four of my scripting
>
additions to scriptable applications, and so far see very little impact on
>
usability.
Fine. I don't know what your additions do -- apps might well make sense for
them. I just don't see that as a basis for your telling other developers
what they should do with theirs.
>
>
Yeah. The message is users are lazy.
Exactly. I'm lazy -- that's why I leaned AppleScript in the first place. If
we weren't so damned lazy, we'd still be happy memorising arcane keyboard
combinations and plugging away at DOS or CP/M.
(There's been some interesting stuff coming out of MacHack. You should read
some of Jef Raskin's writings about the early Macintosh, and how the aim was
to focus more on what the user wanted rather than engineering requirements.
Seems vaguely appropriate.)
>
>
Have you seen the long threads here on the topic of global namespace
>
terminology collisions?
Not for quite a while, actually. But yes, that's part of the price of
scripting additions. If there were dozens coming out every week, the
situation would clearly be chaos. But as it is, most problems seem to be
solved fairly quickly. It's not perfect; what is?
>
How about coercion problems resulting from
>
scripting addition coercion handlers?
Now they are a problem. But given the small number that trap people, and
their clear utility, I can think of a better solution.
But how can you put something like Jon's automatic coercion of a file path
into a file spec or whatever into an app? It wouldn't make sense.
>
Contrast that with the small problem
>
of having to type "tell application". Which one has a more detrimental
>
effect on usability?
If you have to wait for an app to launch, the latter. If you have to have a
dozen or more extra apps running all the time to avoid this problem, then
the latter. If -- and I say if -- there is a speed penalty, then the latter.
>
>
> And then there's the not-so-small issue of speed. Frankly, if there's a
>
> significant speed difference, that alone would be a good enough reason to
>
> jump one way or the other in some cases.
>
>
If you have something other than speculation on speed differences, then
>
please do share. I'd like to see proof that there is a more than negligible
>
speed hit. Otherwise, please stop throwing speculation into this.
Read my paragraph again: I said "one way or the other". In other words, if
an app turns out significantly faster, then I think it would make sense for
that reason alone. And vice versa. No speculation there.
>
>
> I also like the idea of facilities sitting there, not using resources unless
>
> called. With apps, that means launch times, and with OS X, that spells long
>
> delays.
>
>
As with Classic Mac OS, scriptable applications can be made to launch at
>
boot/login and stay running until the next restart. Or, if that's not what
>
you want, they can be made to only launch when you need them and auto-quit
>
when they've been idle for some time. No problem there.
There's at least one potential problem there: time. Have you seen how long
an app takes to launch in OS X?
--
Shane Stanley, email@hidden