Parent property & load script - info
Parent property & load script - info
- Subject: Parent property & load script - info
- From: Sun Real <email@hidden>
- Date: Fri, 2 Feb 2001 14:48:30 +1100
The discussion here early last month on using the inheritance of the
parent property as a means of making sub routine handlers available
without the need for 'tell' or 'of' was *most* useful for me. Thanks
everybody!
I thought I might try to clarify and summarise some of this.
Jason Bruce wrote (in part) on the 9th of Jan:
>
I don't think load script copies the loaded script into the child
>
script, because when I've loaded very large scripts into very small ones,
>
the small ones haven't increased in size. What probably happens is that
>
load script stores a reference to the script to be loaded at compile time
>
and makes a copy of the loaded script in RAM at run time for use in the main
>
script.
I think you will find that loading a script at compile time, either as a
standard script object or as the parent, does in fact add the loaded
script to the child at the time. File size increases as one would expect
here:
script loadTest
--property parent : load script alias "disk:file"
end
--> file size = 686 bytes with a valid (longer) path commented out as
shown
script loadTest2
property parent : load script alias "disk:file"
end
--> file size = 23,376 bytes, the script it loaded was 23,190 bytes
This raises an important issue when using 'load script' in properties -
the child script contains the object that was loaded when it was
compiled. If the parent is changed, the changes will not affect the
child until the child is recompiled. I find this generally helpful, but
it can bite you if you're not aware of it.
If it's important to always have the latest version of your lib, or
you're reading a prefs file, you can load at runtime of course:
on run
set cooLib to load script alias "disk:folder:file"
tell cooLib to doSomethingFantastic()
-- do your other stuff
end run
This also has the advantage of not taking up disk space with multiple
copies of what may be the same script object in each of the scripts that
use it, as noted by Danny Goodman and no doubt others. This is not
really a big deal any more though - disk space is plentiful & cheap these
days.
One disadvantage is that you get a runtime overhead. If your disk is
slow &/or your script object is big, it will take an appreciable amount
of time to load. Not always a practical issue, but it does affect fast
scripts. Another is that it doesn't appear that it allows us to make use
of the parent property, probably the best thing to happen since self
peeling bananas.
I've been using libraries for a while, but the use of the parent property
in this context removes what for me are the two least useful things about
them: tell problems and scope problems. Oh how I wish I'd looked more
carefully at some of Scott Norton's excellent posts on this matter!
When I load a library I have to tell it what to do, as shown in the
example above. As Jason (and Scott and Arthur Knapp) pointed out,
loading it as the parent removes this requirement.
What's even mo' better for me though, is this, flagged by R23 on the same
day:
>
Chaining a number of these together would more than likely
>
result in all handlers and properties accessible to the last
>
script object in the chain. Potentially very useful indeed.
Seems to be exactly how it is too. Now I have a very simple and clear
object hierarchy in my library system and all the handlers from each lib
are available as if they were local, not only to my final script, but to
the libraries 'behind' them. This, as we used to say in Australia when
we had our own language, is bonza mate! ;-}
The only caveat I currently see is that if you change the 'foundation'
lib in a linear sequence, *all* the others down the line must be
recompiled to take advantage of it as noted above.
Again though, this is not all bad. If you have lots of scripts running
all the time and you do the unthinkable and make a non-compatible change
to a lib, your scripts will not all break at once. That's a beautiful
thing IMHO. Only when you recompile each script, (testing as you go of
course) will things fall over, and at least you'll be there when that
happens.
Cheers,
Richard Morton
-- Great Lies of the Music Business: "Someone will be there early to
let you in"