Re: What the heck is this !? (reassigned alias)
Re: What the heck is this !? (reassigned alias)
- Subject: Re: What the heck is this !? (reassigned alias)
- From: Ric Phillips <email@hidden>
- Date: Tue, 10 Sep 2002 12:52:11 +1000
>
But surely this raises a worrysome issue. The alias originally pointed to a
>
folder in my home directory, but the reassignment by ID plunged it deep into
>
the heart of the system. In this instance the script only told the folder to
>
open, but what if it had contained an instruction to move or delete the
>
folder's contents? In that event a case of mistaken identity could easily
>
have led to wrongful arrest, and I'd rather a broken alias than a broken
>
system.
>
>
Or perhaps I'm just being paranoid ;-)
No it's a legitimate concern. Hidden mutability is the issue. The mapping of
file system IDs to file system objects as you point out can change. But then
so can object names and 'relative' positions. It's a matter of how much
information is discarded when such a change occurs compared to how much is
retained. And, how reliably can the lost information be reconstructed from
the retained information.
The file system ID is the 'proper noun' of the run-time environment. It
contains one bit of information. When the mapping changes you lose 0
percent of that information. There is no way at all to recover that
information - worse, know that it is incorrect.
You could bind additional data to the ID; file type, creator type, etc. This
will allow validation, but not reconstruction - and there's the overhead.
The system ID removes the need to code for changes in object attributes like
name and location. But this advantage is built on a statistical safety
strategy, not an absolute one.
After having many scripts fail on me I built my own project framework to
skew the odds in my favour.
First I built a set of handlers, objects, files and folders that function as
an abstract class for every non-trivial app I build. All references in the
source are relative to a single abstract root - a single 'path to me'
"instantiates" that root and all the relatives can be validated and resolved
at run time. (Which is an approach If first came across in the Palaeolithic
era writing machine code for Z80 microprocessors!)
One of those components is a paint text file that basically stores a hash /
dictionary / AS record (whatever) of all the references that are outside the
home directory of the app, but need to be preserved from execution to
execution.
Now one of the things that this allows is the storage of a 'marker file',
within the run-time resolvable package that is the app. You can store the
File System ID for this marker in the preferences file at each run time and
because its relative position in the package can be resolved, you can
compare the ID it has in the current execution with the one it had in the
last. If there is a change you know that the host file system of you package
has had its ID mappings re-initialised (for whatever reason - it doesn't
matter) and re-run you set up code. If you wanted to be thorough, you could
keep and compare this information for every critical path your application
had to store.
After all, programming is all about the variables.
--
Ric Phillips
Humanities & Social Sciences IT Unit
La Trobe University
9479 2792
_______________________________________________
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.