Re: Aliases in AppleScripts
Re: Aliases in AppleScripts
- Subject: Re: Aliases in AppleScripts
- From: Christopher Nebel <email@hidden>
- Date: Thu, 13 May 2004 10:37:28 -0700
On May 13, 2004, at 7:40 AM, Doug McNutt wrote:
At 12:09 -0600 5/12/04, I wrote:
<can't resist>
AppleScript would do well to dump the alias concept altogether and
handle everything as a full path in an OS neXt environment. And get
rid of the file specification typedef too.
</can't resist>
And I erred in the midst of trying to be funny.
But I was, I think, misunderstood and perhaps the point is worth
further discussion. ... The question I have is whether or not such
things are useful while an AppleScript is running. I can imagine a
setup in which an alias file is created in Finder, perhaps in response
to a request from a running script, to provide a pointer to a target
file that might be moved. But I have trouble with a running script
using an alias resource to track a moving target.
When an icon is dropped onto an AppleScript application Finder
resolves any aliases and provides only the final target file. But it
provides it as an alias! Why? I really don't think it's possible for a
user to drop the icon and then move the target while the AppleScript
is running.
This is absolutely possible, especially if the script hangs onto the
"alias" for more than a few seconds. Whatever your "file" object is,
you want its representation to be resistant to the file moving.
(Unless, that is, you specifically want the file at an exact path, but
that's comparatively rare.)
Part of the problem here comes from confusing AppleScript types with
Apple event descriptor types -- something both AppleScript and
scripters have been prone to. AppleScript has historically tried to
maintain a one-to-one relationship between the two, despite the fact
that the distinctions between the descriptor types aren't always
meaningful in AppleScript. This is why "file" and "alias" are
considered separate types, and why "file specification" exists in the
first place. <<class furl>> was an attempt to break this pattern -- it
has no AppleScript terminology, because it was invented to be solely a
transport type. Of course, if you know it's there, then AppleScript
will let you get at it, because AppleScript's original design acts in
places like a very thin layer over the Apple Event Manager.
Various commands return "alias" objects simply because it's the most
durable type -- it's (mostly) immune to the file moving, and is safe
between processes, which "file specification" is not in Mac OS X.
People do indeed store "alias" objects in properties to track files.
Ultimately, however, it's not a good system. There are just too many
file types, and the differences between them are extremely subtle. I
actually have a cunning plan to get down to exactly one "file" type,
but it may or may not ever see the light of day, because it would break
existing scripts that rely on the existence of and semantic differences
between "file", "file specification", "alias", and "<<class furl>>".
I am, however, adamant that files should be considered objects in their
own right -- path strings are not files, and files are not path
strings. Maintaining this distinction is critical in at least some
places, AppleScript syntax being what it is. Consider the difference
in meaning:
length of "Some:string:that:looks:like:a:path"
length of file "Macintosh HD:Users:me:Documents:something clever"
Once you're required to make the distinction in some places, I maintain
that AppleScript should be consistent and require it everywhere.
--Chris Nebel
AppleScript Engineering
_______________________________________________
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.