Re: path to as string
Re: path to as string
- Subject: Re: path to as string
- From: Christopher Nebel <email@hidden>
- Date: Mon, 27 Jun 2005 11:29:17 -0700
On Jun 25, 2005, at 5:05 PM, has wrote:
<http://www.apple.com/applescript/releasenotes/192OSX.html>
<http://developer.apple.com/documentation/Carbon/Reference/
Apple_Event_Manager/apple_event_manager_ref/
chapter_1.4_section_96.html>
A couple of thoughts:
It does seem odd that styled text and international text aren't
straight out deprecated. Like typeText, they can't go away
completely while there are still older applications around that use
them, but I don't see any reason why they couldn't be deprecated now.
"Deprecated" in Apple documentation usually implies that the function/
constant/whatever in question is going to completely disappear
sometime soon-ish. This is not the case with typeText and friends,
since there's way too much existing software that uses them. We
merely recommend that people not use them, since they have problems
working correctly world-wide.
The more I think about it, the more I'm disturbed by the
deprecation of typeText in the Apple Event Manager API [1]. At the
very least, it's way too premature. While typeText is a poor choice/
downright unsuitable for encoding human-readable text - and anyone
still using it this way should be spanked - character strings are
also very commonly used to hold binary data (e.g. zip-encoded
data). While this may not be an ideal practice - it'd be better to
have a dedicated (but still interchangeable) typeByte provided for
this purpose - it's not one that's going away any time soon, and
typeUnicodeText really isn't a suitable alternative here. I think
the disappearance of typeText from AEM will be shooting everyone in
the foot (i.e. not just AppleScripters, but everyone who uses Apple
events), but what's the opinion of the professional programmers here?
If you have a stream of bytes that somehow defines its own encoding,
it's technically not text, but merely data, and you should use
typeRawData for it. The documentation should probably point that
out; both XML and HTML fall into this category, and it's easy to make
that mistake.
To answer m. neuberg's question:
path to desktop as string
(path to desktop) as string
The results look the same, usually, but they are not. If you
examine the AEDesc that's coming back as a result, the first is a
string, the second is styled text. (There is no point asking for
the "class of result"; you are
told "string" in both cases.) I recognize that the two are
different operations (the first has the osax do the coercion, the
second has AS do the coercion), but the use of styled text is odd.
I am told that this is a way of dealing with the possibility of
having to handle an encoding. But since we are advised that styled
text can't handle every situation, I wonder whether this is wise
behavior.
Did you want it to do what you asked, or didn't you? You said,
"convert it to string", and that's what the "string" type in
AppleScript is.
As to why the two results are different, the answer is a little
subtle. In the first case, you really have an "as" parameter to
"path to" with the value typeText. "path to" does the coercion
itself with an output type of typeText, and there you are. In the
second case, "path to" returns an alias, and you ask to coerce it to
the AppleScript "string" type. This is the subtle bit: the
AppleScript "string" type, despite many people's fervent belief to
the contrary, is *not* the same thing as typeText -- it's allowed to
carry style information as well. Alias-to-string involves coercing
the alias to a path, which is always represented as Unicode text for
fidelity reasons, and then Unicode-text-to-string adds style
information because that's how you represent encoding information in
styled text, ergo, you get an AEDesc of typeStyledText.
--Chris Nebel
AppleScript and Automator Engineering
_______________________________________________
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