Re: parent properties - [it's your breath...let's talk scope]
Re: parent properties - [it's your breath...let's talk scope]
- Subject: Re: parent properties - [it's your breath...let's talk scope]
- From: Richard 23 <email@hidden>
- Date: Sun, 4 Feb 2001 19:49:03 -0800
>
I was fascinated to learn of the "parent" property, so I'm testing it. I
>
created a compiled script:
>
>
property a1: "hello"
>
>
and saved it to disk. I then created a script in script editor...
>
>
property parent : load script file "WorkZone:testparent"
>
display dialog a1
>
>
This works as expected - the dialog "hello" is displayed. I then created
>
this
>
script:
>
>
property parent : load script file "WorkZone:testparent"
>
>
my useparentprop()
>
>
on useparentprop()
>
display dialog a1
>
end useparentprop
>
>
This errors saying the variable a1 is not defined. If the properties and
>
handlers of the parent script are treated just as if they were inline with
>
the child script, then the useparentprop() handler should be aware of the
>
property a1.
>
>
Incidentally, the child's handler's are correctly aware of the parent's
>
handler's, just not the parent's properties.
>
>
Any ideas?
Well, this is the reason you don't see large libraries of reusable code.
I have no idea why, but the AppleScript's implementation throws up (how
messy!) a lot of roadblocks to reusable code, a scripter/programmer's
best friend.
Roadblock: path to me doesn't work properly in Script Editor, so you
can't just locate additional required files by looking in the same
folder. Since Script Editor isn't scriptable, you can't ask it to
tell you which file is open or which file is in which window.
Roadblock: Although the resource file is open and available (compiled
scripts, not applets or droplets) you can use a resource tool to get
at encapsulated resources within the same file however the open file
seems to be the most recently opened, not the frontmost, so getting
at the file that way doesn't work either.
But there's a context issue which you've touched on which is more
significant than the editor related hobbles.
First here's my proposed solution, one which I've mostly implemented
with a stay open applet and a consistent filing scheme:
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
If you've sweated for weeks over a script which automates your website
updates, odds are there's a number of handlers which could be generalized
and reused. The obvious thing to do would be to pluck these out, pepper
with comments, add a version resource, a brief header, and a read me file,
uploading it somewhere so that when another user wants to do something
similar, they have to option to build on what you've already done, simply
by a sticking the file in their additions folder or library folder.
The structure I use for this folder's hierarchy is similar to Perl's.
The library folder contains a bunch of folders, each with a general name:
eg, Coercion, List, Number, Record, Resource, Speech, etc
within each is another list of folders with more specific names
eg, CoerceToString, Hex, GetRecordLabels, ResourceTools, etc
one or two levels down is a folder for a specific library and may have
multiple versions (current and previous versions).
eg, SpeechCleanup 1.0a1, SpeechCleanup 1.0a21, ... 1.0a3, etc
Given this structure, the use of an incomplete relative path should
be enough to locate the library file. Continuing with the model,
the addition of a simple load library command would then load the
current version of the library file into the current context and
would be available as if it had been included in the file to begin
with (version would be optionally specified if necessary).
Not too much to ask.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
I've written a script applet which does much of this, and is usually
only needed on the first run after a recompile (it also functions in
a standby mode, keeping a temporary lookup list for previous searches
so successive recompile/runs, common during development are faster).
Given the following property is defined, a call looks like this:
property LibFinder: a reference to application "LibFinder"
tell LibFinder to FindScript("library::Coercion:CoerceToString")
tell (run script file result with parameters "Rev7") to Init(me)
There's also a front-end user interface version which performs
searches via a command line entry using display dialog
The full path is resolved by getting the path to the library from
a preferences file, mapping the general name before the "::" to a
real alias then searching the partial path...
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
This system is flexible and portable and would be released if only...
If only the scoping made sense! People who have said they don't get my
point on this "I've used libraries..." and then I see how, invariably
it's a hardcoded path, which is not a portable method (sorta the point
of a library y'know!) and even if it isn't hardcoded there's the way
it's referenced, "tell FooLib to ..., tell ... to set its..." and it
gets messy because you can't just refer to it as if it were inline.
Per an earlier post I mentioned I have used a method that turns the
model upside down so that the last child is the parent giving global
visibility (addressing the parent through the handler early in the
script makes every object and every property and every handler visible
everywhere, but it can get confusing fast when multiple files make
use of the same libraries.
I'm still occasionally working on a solution to that.
Here it...isn't.
--> sent to JWBaumann... offlist due to complexity **
But a method for this sort of thing should have been implemented better
(or at all) to begin with, for the sake of its users. If you still
don't get my point once again I refer you to the [cpan.org site] and
challenge you to find anything even remotely like that for AppleScript.
You won't because it's just too complicated to use libraries and this
really limits the productivity of new users (as well as experienced)
who cannot easily benefit from the efforts of others who would gladly
provide such files if only a method existed.
Thank you for listening and have a lovely supper.
R23
** if anyone would like to see it, let me know. The fee is
quite reasonable if you have a lot of money and no sense.
Just be careful playing with scope as AppleScript and Script
Editor can occasionally be brutally honest about their feelings
on mistakes which result in infinite regression with regards
to scope.
Crash and boom...and no temp file, so be sure you know what
you're doing. (I usually don't!)
Also keep an AppleScript object somewhere in the scope chain
unless you don't need any Scripting Additions (including Apple's).