Re: decompilation insanity
Re: decompilation insanity
- Subject: Re: decompilation insanity
- From: has <email@hidden>
- Date: Fri, 21 Oct 2005 11:51:12 +0100
Emmanuel wrote:
> >3) regardless of the answers to the above, why, oh why, did the AS
>>folks design file, posix file, and file url this way?
>
>I think that this crucial question did not get an answer, so here are
>my two cents.
>
>"file" is a compact type where the OS stores the file
The actual AS type is 'file specifier', which maps to the Apple Event Manager's typeFSS and the Carbon File Manager's FSSpec. 'file' is one of those really annoying semi-synonyms and homonyms, like 'text', that cause as much confusion for the language as the user. (Especially when the AS compiler arbitrarily rewrites 'POSIX file "..."' specifiers as 'file "..." in your source code.)
FSSpec (and, by extension, typeFSS and 'file specifier') is deprecated in OS X for various reasons described in <http://developer.apple.com/technotes/tn/tn2022.html>, and its use should be avoided except where occasional backwards compatibility issues in gnarly old pre-OS X applications require it.
>What is cool with ´class furlª is that it's an URL: extensible to
>other protocols, with a string representation, multi-platform, etc.
>For instance in Smile 3 you can now transparently edit a document
>through ftp: Smile accepts a ftp or http URL as the "path name" of a
>window, as well as a "file" URL.
Neat trick. Is this an Apple-approved use for typeFileURL, or just something Smile's come up with itself? Do you know if there's Apple documentation describing how typeFileURL should or shouldn't be used?
>The confusion comes from the fact that when asked to display a ´class
>furlª, AppleScript displays file "path:to:file". Don't care about
>that,
You should, since 'file "path:to:file"' has a different meaning to 'POSIX file "/to/file"' when you compile it again. AppleScript helpfully pretty-printing folks' source code for them is good. AppleScript changing that code's semantics is not, especially when those changes can lead to subsequent breakage. Scripters write enough bugs on their own without AppleScript doing it as well. ;p
>and in modern applications get gradually used to the fact that
>more and more commands which expect a reference to a file will accept
>a string which must be a valid URL
Applications shouldn't have to do deal with this sort of crud themselves; that ought to be the Apple Event Manager's job. If folks think Apple should add a typeChar/typeUnicodeText -> typeFileURL coercion to the Apple Event Manager's collection of built-in coercion handlers, file a feature request on it.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden