Re: Running Subroutines from Other Scripts
Re: Running Subroutines from Other Scripts
- Subject: Re: Running Subroutines from Other Scripts
- From: Steven Angier <email@hidden>
- Date: Sun, 25 Aug 2002 15:21:50 +1000
On 25/8/02 10:21 AM, "has" <email@hidden> wrote:
>
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.
My simple rule of thumb would be: if you don't understand OOP then don't
worry -- you won't be using OOP techniques, and (more importantly) it's not
going to affect loaded scripts anyway. Manipulating the top-level parent in
this way simply inserts a transparent layer between the script and it's
parent (AppleScript) -- provided that the top-level parent in the loaded
library has not been changed to something other than AppleScript.
Using this technique, any script object instantiated from within this scope,
will also inherit the loaded script as their grandparent, as will any script
objects instantiated from it, and so on.
>
[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.
I do not dispute this, however AppleScript doesn't care if you use modular
construction or not. It is a matter of personal preference on the part of
the designer.
I once worked with a FileMaker Pro developer who, as part of another
solution, created a suite of files of amazing linear complexity: hundreds of
fields in each; hundreds of scripts. Most of us who later had the pleasure
of reverse-engineering his work (to base it on a more relational model) had
thoughts like "what was he thinking!?!" and "why did he design it this
way!?!" It was just far too complex for any of us to understand in one
sitting.
For him, it wasn't overly complex, or hard to maintain. To him it was
simple, it made perfect sense. My belief is that this person was more
brilliant than all of us put together -- he must have been to be able to
build and maintain such a system. He just didn't "get" the relational model.
The point is, it may be easier for you or I (I know it is for me given my
ever shortening attention span) to maintain modular code, but it isn't for
everyone. When you explain OOD to some people, you can see their eyes light
up and you can hear the cogs turn in their heads as they start thinking on
"the next level". Others think that this way of doing things makes things
more complicated; and still others just don't get it at all.
>
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.
Let's not lump all situations into the "big smear" category. Our base
library (the one with a couple hundred functions in it) really belongs in
the same namespace as AppleScript itself, because all of the functions in it
(with a few exceptions) serve to augment and complete features of the
language.
For example, if I am working with an AppleScript list, I might want to
arbitrarily find the offset to specific items in the list, or find only the
unique items, or remove specific items, or sort the list. Unfortunately,
AppleScript lists aren't that sophisticated. I might then want to load a
library which contains functions that allow me manipulate lists in this way.
I will want that functionality to be a parent to all AppleScript list
objects I create, not just the ones used in a loaded module somewhere.
I feel that some things belong on their own in their own little namespace;
but it often makes sense (to me at least) to have some functionality as part
of the global namespace.
>
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.;)
Namespaces aren't always convenient or appropriate. Imagine if C-based
languages made us refer to ALL of its libraries in their own namespaces:
stdio.printf("Hello world from the stdio.h namstpace!\n");
Or
iostream.cout << "Namespaces aren't always good.\n";
Not exactly convenient.
>
>> 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:).
At 100x improvement, it shouldn't be long before your scripts take over the
world :-)
>
[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].
I'm not sure what you mean here. If you mean something along the lines of
the following code, then this is exactly what I would expect.
script a
property x : "a"
on foo()
return x
end foo
end script
script b
property parent : a
property x : "b"
on foo()
return x
end foo
end script
a's foo() --> "a"
b's foo() --> "b"
b's parent's foo() --> "a"
Here, the wrong thing to do would be to rename either foo() handler
(assuming that both foos have similar, though object-specific purposes) as
that would prevent polymorphism.
Think about the metaphor of a database schema: schemas contain tables;
tables contain rows; rows contain cells; cells contain data. It would make
sense that when changing the data contained in a given cell, the objects up
the hierarchy should be notified. The schema class might have an "update"
method. The table class would probably override the schema's update method
with its own, but in it would be a call to it's parent's update method.
You know all of this all too well, so I must be misunderstanding your point.
>
[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.
Nearly all of the functions are documented in the supplied dictionary, the
PDF and the Script Debugger clippings. The rest use underscores to help
avoid collisions.
Steven Angier
Macscript.com
_______________________________________________
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.