Re: TIDs case insensitive?
Re: TIDs case insensitive?
- Subject: Re: TIDs case insensitive?
- From: Nigel Garvey <email@hidden>
- Date: Sun, 11 Mar 2001 15:11:03 +0000
"Arthur J Knapp" wrote on Sat, 10 Mar 2001 12:02:06 -0500:
>
> Subject: Re: TIDs case insensitive?
>
> Date: Fri, 9 Mar 2001 11:29:21 +0000
>
> From: Nigel Garvey <email@hidden>
>
>
> like to see the TID's made less of a production number and less permanent
>
> in scope. For instance, they could be used as individual command
>
> parameters (as with the 'read' command) instead of being long-windedly
>
> set until reset. This would also (in theory) lessen the effort of
>
> resetting them should anything go wrong while they're at non-default
>
> values.
>
>
>
> set fred to text items of pathString using delimiters {":"}
>
>
This is interesting.
>
>
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}'?
>
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
>
-- stuff
>
end
[...]
>
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.
(I agree though that aesthetically, it leaves an itch that can't quite be
scratched. :-( )
>
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. I can see how it might lead to problems in some
circumstances, but otherwise it's a convenience - like the similarly
extended scope of a 'try' block. If a handler's called within a
considering/ignoring block, it suggests that the conditions are meant to
govern its behaviour as well. If certain conditions would adversely
affect its operation, it can always have its own considering/ignoring
commands, which would temporarily override those in force at the calling
point.
Hmmm. This gives me cause to rethink my case-insensitive offset
handler....
NG