Re: Running Subroutines from Other Scripts
Re: Running Subroutines from Other Scripts
- Subject: Re: Running Subroutines from Other Scripts
- From: has <email@hidden>
- Date: Sun, 25 Aug 2002 01:21:45 +0100
Steven Angier wrote:
>
It is often simplest to have one attached library, loaded into the current
>
script's namespace via the parent property:
>
>
property parent: load script (alias "path to library")
IMHO I'd be _very_ wary of suggesting this approach to anyone. The 'parent'
property is an OOP [1] feature - part of AS's inheritance mechanism - and
my simple rule of thumb would be: if you don't understand OOP then don't
use it - you're not in a position to judge whether doing so is good or is
bad.
-------
[And here's a longer explanation, if anyone's feeling keen...:]
By using modular construction, you break your design up into discrete,
self-contained chunks that are easier to work with and think about than a
single large sprawl of rats-nest code. The connections between modules are
made completely apparent, and the risk of accidental interactions occurring
between modules is avoided because each module's code is safely tucked away
in its own namespace [the 'insides' of the script/script object that's
being used as the module]. So modules are good, and certainly to be
encouraged in projects that will benefit from them - it's how you go about
incorporating them that's traditionally been the awkward part in
AppleScript.
Now, I realise that some folks may find typing "foo's bar()" instead of
just "bar()" to be a bit tedious. However, this turns out to be trivial
compared to the work needed to test and debug a large application where the
various components are all effectively smeared together. So stick with it.
[2]
Returning to the problem with the "simplest" approach of using inheritance
to 'import' your module: once you have two modules sharing the same
namespace, you're actually returning to the "big smear" again, thus
_complicating_ your design when you meant to simplify it instead. The
interconnections cease to be clear and well-defined, and you reintroduce
the risk that accidental interactions might occur between the modules [3].
So whilst on the surface it might seem simpler, the hidden implications
mean it's anything but. [4]
-------
IOW, namespaces are your friends and you should take every advantage of
them. 'Nuff said; and here endeth the lesson.;)
>
> BTW, I think the next version of ASS may allow multiple scripts in the
>
> same app to communicate with one another,
>
>
Can anyone confirm this?
Well, there's every chance that I'm just being delusional again, so do take
it with the mandatory bucket of salt. Even I'm not sure anymore if the
voices I hear hinting at these things are real or not. ;p
However, it's definitely top on my own list of 'Things I Really Want To See
In ASS Before I Spend Much Time On It', so if anyone does know Yea or Nay,
I'd also _very_much_ like to know. (As the rest of this long and probably
very boring mail suggests, it's something I consider fairly important.;)
Regards,
has
p.s. I've abused inheritance - and just about every other language feature
too - often enough myself (before finally picking up an OO book and
learning about this Design stuff properly), so if the tone of this writing
seems critical, the criticism is aimed entirely back at myself... (or, more
accurately, at the 100x worse coder I used to be:).
--
[1] OOP = "Object-Oriented Programming"
[2] I've been through that stage myself - it's just a phase, growing pains
as you transition from rank amateur ["Pah! Who needs handlers anyway?"]
code splurger to something a bit more skilled [or even, dare I say
"semi-professional"?]. Better things lie on the other side; what else can I
say? <g>
[3] For example, if script A has a handler called "foo()", and script B,
which inherits from A, also has a handler called "foo", then whenever A
tries to call its foo() handler it will actually end up getting B's foo()
instead. Your wires get crossed and your script breaks as a result. Ouch.
Of course, there is a way around this problem: avoid using any handler
names in module A that might be used in module B, and vice-versa [3a].
Except this means you've now need to know all about B when writing A, and
all about A when writing B; essentially defeating the whole point of
modular construction, which is to avoid these sorts of ghastly
Juggling-Fifty-Items-At-Once Acts in the first place.
[3a] Incidentally, this is good as impossible with something like [e.g.]
Steven's library: with a closed-source component third-parties can't open
it to find out what all its handlers are called, so there's no way to avoid
the risk of conflicts.
[4] Of course if you're doing what I did when I began to make things
modular, which was to write on big, ginormous script and then try to break
it up afterwards as a sort of remedial action, you won't really _see_ any
of the benefits of a truly modular design. There's a huge difference in
quality between a genuine modular design that's been built from the ground
up, and a giant code splurge that's been retroactively hacked into pieces.
Indeed, parental abuse might seem quite a tempting solution with the latter
because it lets you quickly and lazily reconnect the various sections again
without having to change the actual code significantly. Just don't go
thinking that you've magically produced a modular design, however, because
all you've really created is a thoroughly gnarly hack.:p
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.