Re: TIDs case insensitive?
Re: TIDs case insensitive?
- Subject: Re: TIDs case insensitive?
- From: "Arthur J Knapp" <email@hidden>
- Date: Mon, 12 Mar 2001 11:35:43 -0500
>
Subject: Re: TIDs case insensitive?
>
Date: Sun, 11 Mar 2001 15:11:03 +0000
>
From: Nigel Garvey <email@hidden>
>
"Arthur J Knapp" wrote on Sat, 10 Mar 2001 12:02:06 -0500:
>
>> From: Nigel Garvey <email@hidden>
>
>> set fred to text items of pathString using delimiters {":"}
>
> It would turn the syntax "text items of" into more of a command
>
>than a property/reference, which might have it's own drawbacks,
>
>but the concept is very sound.
>
Yes, I'm afraid my suggestion blithely disregards what would have to go
>
on under the bonnet to make it work. And what would happen in the case of
>
the complementary effect: 'set bill to theItems as string using
>
delimiters {return}'?
Right. AppleScript is not Perl, but why not think in terms of
"there's more than one way to do it"? I think that a "using delimiters"
systax, implemented as both a single line qualifier and as an execution
block would be a wonderful addition to the langauge, (and the current
tids system could certainly be kept around as well, with tids blocks
temporarily overiding the global setting).
>
> With regards to considering/ignoring statements, I would
>
>like to see the "parameters" changed to evaluated constants, ie:
>
>
>
> set variable01 to case
>
> set variable02 to hyphens
>
> considering variable01, variable02
>
> It is very frustrating when creating a general purpose handler
>
>that two separate code blocks must be created to allow for
>
>different comparison systems/algorithms.
>
Well... if the blocks contain different code, that's fair enough. If they
>
contain the same code in different 'considering/ignoring' blocks, then
>
the code need only be a call to a handler - as your next point suggests.
Yes, proliferation of handlers is our friend. :)
>
> While there are many problems with the fact that the tids
>
>are "global" in scope, there is a similar problem with the
>
>fact that a considering/ignoring statement will extend into
>
>it's enclosed handler calls:
>
>
>
> ignoring white space
>
> -- stuff
>
> my compareFunction(a, b) -- white space will be ignored
>
> -- stuff
>
> end ignoring
>
>
>
> This makes it very difficult for someone who is attempting
>
>to make distributable script libraries to protect against.
>
>
You were kind enough to endorse my idea, but I'm not sure I agree with
>
you 100% here.
WHAT!!!
Fine, then I'm not 100% behind your suggestion. In fact, I'm pretty
sure that I am less than 98% behind it. ;-)
>
... I can see how it might lead to problems in some
>
circumstances,
In my case, a lot of circumstances. I use a lot of "generic" handlers,
that I either cut-and-paste from other locations or that I bring in from
script libraries. I also use a lot of considering/ignoring blocks in my
scripts, (they are often convienent for implementing clever algorithms,
which is important since I have a natural aversion to using timesaving
third-party scripting additions).
As a result of the very "generic" nature of my handlers and script
libraries, it frustrates me that the calling script can screw them up
by changing the global tids, or by calling them from within considering/
ignoring blocks.
>
... but otherwise it's a convenience - like the similarly
>
extended scope of a 'try' block.
But a try block simply captures an error, it's scope doesn't
affect the execution of it's enclosed handler calls.
In any case, it's not a big deal. For my own purposes, a single
line method of setting considerations, like:
set bool to x = y ignoring white space
would be at least as useful to me as your suggestion, but I can
survive without it. :)
Arthur J. Knapp
http://www.stellarvisions.com
mailto:email@hidden
Hey, check out:
http://www.AppleScriptSourceBook.com