Re: persistence [Was: Re: difference between property and variable]
Re: persistence [Was: Re: difference between property and variable]
- Subject: Re: persistence [Was: Re: difference between property and variable]
- From: has <email@hidden>
- Date: Tue, 11 Dec 2007 18:09:30 +0000
Brennan wrote:
- A property's scope is limited to the script object in which it's
defined. e.g. If you define a property in your main script, that
property will cease to exist when the script finishes running
...he might have been [mis]understood to mean that the properties lose
their values between executions. I'm sure it's not what he meant,
but I
just wanted to nitpick his otherwise thorough answer.
You may well be correct re. misunderstandings. I deliberately avoided
discussing long-term persistence issues in my original post, as that's
another can of worms and not directly related to understanding the
difference between different variable types, which is what the OP was
asking about. But since it's come up, I'll try to explain it here:
My statement that a property defined in the main script [object]
ceases to exist when the script finishes running is quite correct...
except for the phrase "when the script finishes running" is somewhat
ambiguous and could be misinterpreted. What I specifically mean is
"when the script is disposed of", and that's something that can happen
at different times depending on when the host process decides to do
it. e.g. Script Editor will dispose a previously compiled script when
recompiling it from source, or when its script window is closed. A
script applet will dispose of its main script object just before it
quits.
Now, where things get interesting is that some (but not all)
applications provide persistence of script data beyond the destruction
of the original script. They do this by asking the OSA for a
serialised ('flattened') copy of the original script [1], which they
can then save to disk or otherwise store away for later use. This
allows them to reload that serialised copy later on and convert it
back into a live script, complete with the global and property values
it had when it was saved.
So, two things to note here:
1. To be precise, it's not the properties and globals that persist;
rather it's the top-level script and everything in it. Also, remember
that the original values are still destroyed when the original script
is; the next time you load and run the script, what you're using is
copies of those values that were made when the script was flattened
for storage.
2. This persistence behaviour is not a function of the properties and
globals, or even of AppleScript itself. It's actually a feature
provided by the application that's using the script, and one that they
must explicitly provide for persistence to happen at all. Some
application do (e.g. applets); others don't.
Why is this relevant? Because this is one of those areas where
AppleScript is fuzzy and inconsistent and most folks have a less than
100% accurate understanding of how it actually works. As a result, the
usual statement that "properties persist between runs" which is often
churned out is only accurate up to a point, and while it may be near
enough to the truth to carry folks along for a bit, sooner or later
they encounter a situation that clearly contradicts this belief (e.g.
properties that don't persist between runs [2]; applets that
mysteriously balloon in size or throw a table overflow error after
running [3]), leaving them more than a little confused.
Of course, the problem with explaining all this stuff accurately is
that it creates rather more information for the OP to digest, which is
why I didn't want to touch on it in my original response;
understanding scope is the important thing, and once they've got that
nailed down correctly, secondary details like persistence can easily
be filled in later on as needed. Wish it was easier, but that's
something that can only be fixed by fundamental improvements to
AppleScript itself.
HTH
has
[1] The technical details: the application calls OSAStore() on the
original script, which returns an AEDesc of typeScript that can later
be turned back into a 'live' script by passing it to OSALoad(). (For
developer convenience, OS 10.3+ also adds OSAStoreFile() and
OSALoadFile() which write/read the flattened script data directly to/
from .scpt files.)
[2] Answer: Remember it's up to the application to provide persistence
by saving and reloading the main script. Many applications don't do
this, in which case you need to make your own arrangements to store
any data that needs to persist between runs.
[3] Answer: It's not just properties that persist but globals too.
(Which is obvious if you understand that their lifetimes are tied to
the scripts that contain them.) So if you've stored large/complex
values in globals (including top-level variables which are global by
default) then you need to watch out for those as well as large/complex
values stored in properties.
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden