Re: Reverse Offset (was Getting the Folder name when using drag-&-drop Scripts)
Re: Reverse Offset (was Getting the Folder name when using drag-&-drop Scripts)
- Subject: Re: Reverse Offset (was Getting the Folder name when using drag-&-drop Scripts)
- From: Christopher Nebel <email@hidden>
- Date: Fri, 12 Mar 2004 10:56:15 -0800
On Mar 12, 2004, at 2:09 AM, jj wrote:
On Mar 11, 2004, at 1:27 AM, jj wrote:
Hey, I like that 'reverse' method. Now I've made a nice routine:
on ReverseOffset(ftxt, wtxt)
local ftxt, wtxt, ftxt_r, wtxt_r, o_r
set ftxt_r to (reverse of characters in ftxt) as string
set wtxt_r to (reverse of characters in wtxt) as string
set o_r to (offset of ftxt_r in wtxt_r as string)
if o_r is 0 then return 0
2 + (length of wtxt) - o_r - (length of ftxt)
end ReverseOffset
Only briefly tested just now, but seems to do right.
Though now, in Panther, your routine will fail ... You need now the
"considering case" statement for "offset of":
What you call failure, I call behaving like all the other string
operators. This was a documented change. If you want to consider
case, then yes, you should add a "considering case" block somewhere,
but I'd argue that inside the handler is the wrong place, since then
it won't act like regular "offset".
Well, the we can rewrite my comment as "though, your routine will fail
in all known systems, except for Panther, which finally introduced the
normalization and usage of default 'case insensitive' for all its text
routines".
See, I just don't consider this a failure. Both versions are working
as they were documented to work. Yes, it behaves differently -- it's
always case-sensitive pre-Panther, and now it obeys the considerations.
If you consider any difference in behavior a failure, then, well,
there you go, but we're going to have to apply filters when talking to
each other.
I really never understood why in this and other languages
case-insensitivity
is the default behaviour. Conceptuallly, I can't understand how ASCII
"a"
can be never considered as ASCII "A".
(I think you wrote "never considered" when you meant "ever considered",
or else you're contradicting yourself.) If you consider letters to be
pure data, and that no code point is ever equivalent to any other code
point, then yes, that's true. However, you'd be ignoring hundreds if
not thousands of years of linguistic behavior. To most people and for
most purposes, "Bob", "bob", and "BOB" are all equivalent -- they all
refer to Bob. AppleScript is biased towards human conceptions, not
machine ones, so by default it ignores case. (You might find it
enlightening to read the first section of TN2106.)
And others are terribly funny, such as "tr" or "dd":
do shell script "echo -n 'blah' | tr '[:lower:]' '[:upper:]'" -->
"BLaH"
That does seem quite odd, but both that and the equivalent "dd" command
work fine for me on 10.2.3. What are you using? (And was that really
an "a"? Not some accented variant thereof?)
Also, I've revisited a long-time forgot question, and I report/ask
here about it. It's about ASCII character 245, aka "lowercase dotless
i", whose alter-ego in the "capital side" of the life should be the
"uppercase dotless i". So, ignoring case by default, the following
expression evaluates to true:
set lowercaseDotlessI to (ASCII character 245)
lowercaseDotlessI = "i" and lowercaseDotlessI = "I"
--> true
Which should be as false as the expression "i-acute is equal to i", as
far
as I understand it.
There appears to be some sort of bug/inconsistency in how this
comparison is handled in the "string" class. If you compare them as
Unicode text, you'll get false. (In fact, it's *really* false, since
the lack of a dot isn't a diacritic, according to Unicode, so even if
you say "ignoring diacriticals", you'll still get false.)
--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.