Re: Scope of globals, parents and children
Re: Scope of globals, parents and children
- Subject: Re: Scope of globals, parents and children
- From: email@hidden
- Date: Tue, 22 May 2001 21:30:14 -0400
On Tue, 22 May 2001 16:18:42 +0200, Brennan Young <email@hidden> opined,
>
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.
Maybe I should review some history on the reason I included this statement.
This programming/scripting dichotomy is a recurring theme on this list (and I
don't want to bring it back to life as part of this thread!) and I was
originally a vociferous partisan of the programmers, yelling "Use the whole
language! Write maintainable code!" But then I was taken aside and given some
perspective that moderated my stance.
This list has a wide audience, and they don't just range on a a one-dimensional
spectrum from beginner to wizard. Many people use simple AppleScripts to do
complex and important things, integrating their workflow and making a real
difference to their business. And one of AppleScript's compelling features is
that it enables that value.
In more practical terms, the list has thousands of subscribers, and most don't
need to define a handler, let alone a script object. They write small scripts
with a few variables and a few tests, and strap them on to Quark or Filemaker or
Multi Ad Creator, and they have an industrial strength solution. But if someone
comes to this list looking to learn to do this, and sees nothing but discussions
about how to implement multiple inheritance in script objects, callbacks, and
whether or not the random number generator is gaussian or uniform distribution,
he or she may be a little put off. And its impolite to discourage a thousand
people.
>
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.
If you are doing a real development project, with large scripts, yes. But if
you are controlling an application with small scripts, no. And a major part of
the value of AppleScript is controlling an application with a small script.
Its a shame that not all applications implement the object model well, and that
there are broken dictionaries. Its a particular shame because it undercuts this
vital philosophy, that simple scripts can control powerful applications and thus
quickly create powerful, customized systems.
>
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.
Nor would I. But scripting additions are really part of the application side,
not the programming language side. The interface is different, but not much.
You send the AppleEvent, and app or the OSAX does the work and sends a reply.
>
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).
Quite true, if you are doing real programming (as you and I and a few others
here do.) But for everyone who needs this, there are ten who don't. The cool
thing about AppleScript is that you can do great things with a script so small
you have no need for tools that manage complexity.
>
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.
Sure, this is a good example of why sometimes you need the skills of a
programmer. But for the audience of this list, an overemphasis on programming
skills is inappropriate. (And I'd consider what your script to be doing "heavy
lifting", like loading sacks of potatoes on a truck. Manipulating the movie
data is in a whole 'nother level of difficulty; like lifting the truck trailer
onto a container ship. But that's where my homespun analogies start to look
frayed.)
>
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 do agree, and I'm torn between the two conflicting requirements of this list.
Because the combination of a capable application and a small script is so
powerful, you can write a script without learning the whole language. But as an
employer of programmers and developers, I'm seeing many people who learned to
program not through the academic channel, where they learned modern development
methodologies, but from application oriented backgrounds. Artists who learn
HTML, then Javascript. Headhunters who learn to use MS Access, then write
macros, then write Visual Basic code. Many are self-taught, and then gain
experience in a community of other self-taught people, none of whom have ever
heard of Djikstra or Booch. So I can understand why its important for beginners
to have exposure to modern software development methods. There is definitely an
object-oriented mindset, and it harder to obtain it if you first start out with
a procedural mindset. Its sort of like Djikstra's complaint that students who
learned Basic were harder to teach programming than those who had no experience
at all.
>
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.
This is an interesting development. Since I pre-date the object-oriented
revolution, I don't know how computer languages are now taught. I'd hope the
teaching would begin with objects, but I fear they teach programming the way
programming developed: first operations, then procedures, then objects. It
would be like teaching that the earth was flat and made of four elements, then
that it was round and made of atoms. (But no one starts learning physics with
Einstein and quantum theory; they start with Newton and Bohr and then learn the
difficult truth later.)
>
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.
I hope that my approach to script objects has not been to put a wall up that
will discourage those who need to use them. I think that if someone mentions
globals, "load script", libraries, or the 32K limit, they need to be told the
truth about object-oriented design and script objects. Perhaps its like when a
child asks, "Where do babies come from?"
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden