Re: Scope of globals, parents and children
Re: Scope of globals, parents and children
- Subject: Re: Scope of globals, parents and children
- From: Brennan Young <email@hidden>
- Date: Tue, 22 May 2001 16:18:42 +0200
- Organization: Magic Lantern
email@hidden, wrote:
>
AppleScript is primarily about controlling applications, and the application,
>
not the script should define the objects. The application, not the script,
>
should do the heavy lifting."
Well, I disagree with this.
Given that so few applications have really good dictionaries, and so many
dictionaries are 'broken' in various ways, and (worst of all) many don't define
objects at all, it becomes important to be able to roll your own objects if you
really want to use Applescript effectively.
OSAXen are just as much a part of the Applescript universe - arguably a larger
part - than application dictionaries. I wouldn't be without Akua Sweets for example.
In addition, script objects and multiple handlers are not 'heavy lifting', they
are merely ways to manage complexity. Like I said before, the most important
resource for any programmer is attention, so you need to be able to wrap stuff
up and hide it so that you don't get distracted by it when you are working on
something else. (Not to mention the maximum script size limit).
An example: I use Quicktime Player a great deal for editing of movies, but
Quicktime player has no way of storing 'in and out points' for editing purposes.
I made a script which stored selections in the timeline. You open it from OSA
menu and it asks you if you want to store the current selection or load one
that is already stored. It's smart enough to recognise which movie you are
editing, so each movie can have its own library of timeline selections that can
be retrieved at any time.
(BTW the source code is available on request)
This would have been extremely difficult to achieve without using script
objects. My script does not manipulate any actual movie data at all (that would
be my idea of heavy lifting), it just allows you to store and retrieve in and
out points on a per-movie basis.
I have a very simple 'movie' object defined (much more simple than that defined
by Quicktime player) and it contains a list of selection objects - which I also
had to define, plus handlers for retrieving and storing those selections.
The objects *must* be defined independently of their namesakes in the player
because they are stored independently of the selections made in the player, and
because a 'selection list' object is not one of the properties of Quicktime
movies in general.
Don't assume that these things are too advanced to understand. The main problem
is lack of decent documentation, which leads to continuing ignorance, which
leads to the idea that using script objects is too advanced to be really useful
to the casual applescripter. We're only now starting to see online tutorial
material in any quanitity, and Applescript documentation is still not exactly
thick on the ground.
I've seen a similar pattern in the Director community. At one time, (pre 1996),
object oriented Lingo was considered a hallowed, advanced topic, not covered in
many books, and difficult to understand. Most people just didn't bother trying.
What happened? Well some creative people started explaining it so that non geeks
could understand it and now almost everyone is doing it that way. There are now
a dozen or so good books explaining these once-considered 'advanced' topics to
beginners, so that many people now learn object oriented lingo pretty much from
the outset.
Script objects are one of the most powerful features of Applescript. I
understand that beginners have to crawl before they can walk, let alone run, but
please don't consign script objects to the 'too geeky for me' bin without a
second thought. Thanks.
--
_____________
Brennan Young
Artist, Composer and Multimedia programmer
mailto:email@hidden
Knowledge is like a circle. Ignorance is the area outside it. With learning, the
circle grows, and the boundary between knowledge and ignorance increases.
The more you know, the more you know you don't know.