Re: Running Subroutines from Other Scripts
Re: Running Subroutines from Other Scripts
- Subject: Re: Running Subroutines from Other Scripts
- From: Paul Skinner <email@hidden>
- Date: Wed, 28 Aug 2002 23:13:20 -0400
I'm still trying to parse some of this...
On Friday, August 23, 2002, at 02:11 PM, Adam Backstrom wrote:
Hey everyone,
I'm working on a series of AppleScripts written in AppleScript Studio.
For the sake of organization, I would like to split up the code into
several scripts. The problem is, I can't find the correct syntax for
telling an outside script to run a subroutine. Is this functionality
supported?
Ok, Adam wants to load subroutines into his main script. Seems simple
enough. Why doesn't this group get together and roll up a FAQ?
On 24/8/02 9:17 AM, "has" <email@hidden> wrote:
For a standalone ASS-based app, a simple static arrangement is
probably best:
property moduleName : load script (alias "path to module")
...
tell moduleName to doSomething()
Solid suggestion. Simple; works. moduleName...hmmm...
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")
Some development environments (such as FaceSpan) don't allow this, but
AppleScript Studio does allow it.
Yep, Good point. If you have 5 subroutines and you're going to load em
all anyway... Glad to hear that you can still do this in a Studio app!
I can think of other ways, but that's two good ones.
On Saturday, August 24, 2002, at 08:21 PM, has 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
Huh? It's a feature. What does it's nature have to do with keeping it
hush-hush?
Besides, on p.325 of the ASLG: AppleScripts script objects have
capabilities common to object-oriented programming languages.
So why just pick on the parent property? Why suggest script objects as
the alternative?
- 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
Or use it and try to figure it out when odd things happen. I guess I
just think that a quick post explaining the common problems would be
more useful than a 'Beyond Here there be Dragons!' post.
I really dont see any difference in the two suggestions in this
instance. If the library contains only this one handler then the only
difference would be the property definition that visibly declares that
you have the handler available. While I see the value there, I don't
get that from any built in function or OSAX and yet I still write code
that doesn't blow up. If the library contains many handlers then the
two methods are still only differentiated by visible handler
definitions.
So, what's your issue with the parent property?
- you're not in a position to judge whether doing so is good or is
bad.
However, Every AppleScripter uses the parent property whether they know
it or not. The default value for the parent property is the current
application which is 'AppleScript'. By defining it, at least it's made
clear.
-------
[And here's a longer explanation, if anyone's feeling keen...:]
I feel kinda keen.
By using modular construction,
I can't find a reference to 'modular' earlier in this thread in which
you define what you mean by modular. Later it appears you are referring
to script objects exclusively. It looks to me like the difference you
are espousing comes from the idea of loading script objects. Nothing
wrong with that, but I don't see how that has anything to do with the
parent property as a way of loading handlers.
Is that the crux of your point? That every handler should be packaged
in a script object?
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.
When I read that I think 'ah yes, handlers.'.
The connections between modules are made completely apparent,
How so?
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].
Ah, I infer that you imply (covering my bases) that there can be
namespace collision between handler names. There really isn't any
difference between the variables within script objects and handlers, so
I don't think that's the issue.
If I'm right and this is your point, you are suggesting script objects
as a way of creating new namespaces to resolve this. Why not use the
existing namespace up first? What's the limit on variable name length?
If you're going to make a function then give it a unique name or do
like all the OSAX and standard functions do and put 'em right in the
namespace where the other functions are. Let the scripter beware. It's
not like this doesn't happen already.
And if namespace preservation is your only goal then you could clean
it up a lot by changing the script's parent and specifically telling
AppleScript to perform it's functions.
property parent : me
tell AppleScript to beep
-->ding!
beep
-->+script; doesn't understand the beep message.
Now that's a clean namespace!
So modules are good
Um, Ok. Script objects are good. Handlers are good. OS X is gooood. (It
really IS!)
, and certainly to be encouraged in projects that will benefit from
them
Sure. But can we still tell people about the parent property too? : )
it's how you go about incorporating them that's traditionally been the
awkward part in AppleScript.
And it doesn't seem like 10.2 has changed this. I guess I can start
working on that script server project again.
I haven't missed the recent posts, but they haven't resolved this all
for me either.
Later posts ...
And what's so awful with using "listLib's listOffsets(x)" anyway?
Nothing. And when using script objects it's even necessary. I fully
support your right to do it however you want.
[3] For example, if script A has a handler called "foo()", and
script B,
which inherits from A [blah-blah-blah]
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.
No, I meant something like this:
======================================================================
script a
property x : "a"
on foo()
return x
end foo
on bar()
foo()
end bar
end script
script b
property parent : a
property x : "b"
on foo()
return x
end foo
end script
b's bar() --> "whoops!"
-->"b"
The only problem I see here is that you've got top level properties in
a script that's to be loaded as a library and that property is used
internally by a handler of the library. That's a really bad idea,
scope wise. If you were to make a library that contained handlers that
are properly formed they wouldn't have properties floating around on
the top level like that. Handlers in a library are normally fully self
contained, or at the very least, you could make them so. If you want or
need to have top level properties then you have to create a script
object because you can't put properties in handlers.
and then On Sunday, August 25, 2002, at 11:24 PM, Michael Sullivan
wrote:
Now what I'd say here, having done a little OOP, is that the result of
*your* script is correct, it's what happens when b doesn't have a
"foo()" that doesn't make sense.
Nope. It's wrong. But it's wrong correctly. I mean that it follows the
ASLG for scope. script b does have a foo(). It got it from it's parent
script a. And foo() of script a would normally use script a's property
x but...
The scope of a property declaration at the top level of a script
object extends to
any subsequent statements in that script object. Heres an example.
script Joe
property currentCount : 0
on increment()
set currentCount to currentCount + 1
return currentCount
end increment
end script
tell Joe to increment() --result: 1
tell Joe to increment() --result: 2
When it encounters the identifier currentCount at any level of the
script object
Joe, AppleScript associates it with the same identifier declared at
the top level
of the script object.
-ASLG p.317
It wasn't meant to drift off into a debate about OOP; rather my
argument was that procedural coders who wish to write modular code
shouldn't have to deal with OO issues. (In fact, they shouldn't even
need to be aware that such issues even exist.)
Why try to protect people from learning something? Procedural coders of
the world beware!
Really, AppleScript is all about approachable power. This stuff isn't
hard. Even I get it.
The trouble with Steven's suggestion of using the parent property to
'load' modules is that it _does_ expose these folks to said OO issues
whether they like it or not.
How so?
Which goes against what we both seem to agree on: that non-OO coders
shouldn't need to deal with OO issues in order to write their scripts.
Sure they should. AppleScript is chock full of OO stuff. But it's like
frosted granola, if you don't tell them what it is they'll just eat it
and like it.
Folks who are fortunate enough to understand both procedural/modular
and OO practices are at least in a position to make educated
judgements about which approach to use. Those who don't are best
steered well away from such "expedient but unsafe" practices and
towards more conventional techniques that will do what they need,
albeit in much less exciting fashion.
I still don't see your point. What specifically are you suggesting
people should do when they want to load multiple subroutines into a
script?
Sorry if this sounds a bit "I know best; do as I say", but the
pedagogue in me won't let go.<g>
Hmmm...
ped7a7gogue n. One who instructs in a manner that is marked by a
narrow, often tiresome focus on or display of learning and especially
its trivial aspects. Characterized by an authoritative, arrogant
assertion of unproved or unprovable principles.
Hey, I didn't say it, I just looked it up, paraphrased and quoted it : )
--
Paul Skinner
_______________________________________________
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.