AppleScript's Place In The Universe (was Those Darn Email Character Mappings)
AppleScript's Place In The Universe (was Those Darn Email Character Mappings)
- Subject: AppleScript's Place In The Universe (was Those Darn Email Character Mappings)
- From: "Jason W. Bruce" <email@hidden>
- Date: Fri, 05 Jan 2001 17:42:55 +0000
Richard23,
I'm not sure I understand your criticism of AppleScript's features
for writing modular, reusable code. I think AppleScript does quite well in
this respect. Sure, every script object has its own context, but this is by
design and is considered to be a good thing. It prevents namespace
collisions. I also am not sure I understand your criticism of AppleScript's
inheritance mechanism. The mechanism itself works fine for me, whether I
declare a parent to be an external file or a script object in the same file,
and whether I load it at run time or at compile time. If I have to copy and
paste or reinvent the wheel, it is usually a sign that I can design my
scripts better, in which case I move handlers and properties around until
everything fits in place.
Jason Bruce
>
** CAUTION: Editorializing and personal opinion follows **
>
>
I suppose I could start griping about how difficult it is to write
>
modular reusable code which would make the copy and paste method of
>
scripting we communicate here less necessary but I guess I'll save
>
it for later. But it would sure be nice and a lot easier to manage
>
and write scripts if one could simply reference an external file or
>
two and have the sum of the included files execute in the same context.
>
As it works now, script objects loaded from external files aren't
>
even aware of other script objects and getting them to communicate
>
at all, much less inherit properties and handlers is so difficult
>
and non-intuitive that writing scripts involves more copy and paste
>
or reinventing of the wheel than it really needs to be.
>
>
Take a look at www.cpan.org to see what happens when a scripting
>
community has the option of writing and sharing modular reusable
>
code. You wind up with powerful modules that perform everything
>
under the sun.
>
>
Then we'd be exchanging libraries of like handlers, making scripts
>
much easier for the novice and more powerful (and a shorter
>
development cycle) for more advanced users. It sure seems like
>
load script should perform that function but since it does not
>
we really need or some form of import command to make AppleScript
>
more convenient for end users.
>
>
Whenever I write anything in Perl or JavaScript I have ready
>
access to just about every routine I've ever written available
>
to me with a simple import method and I know when I last updated
>
a function because it's in one place, not existing as several
>
incarnations strewn about the 400mb or so of applescript code
>
I have generated over the years.
>
>
I've been working on such a system for building scripts from a
>
central library of common routines selecting the most recent
>
version from a core set and will probably end up with an app
>
that builds stand-alone copies for distribution. Too bad about
>
the 32k text limit though...some finished projects won't be
>
viewable in Script Editor...another issue that should have been
>
fixed years ago.
>
>
>
Rant mode off.
>
>
So much for saving my second rant for later. Am I alone in this?
>
>
R23