Re: TIDs info summary
Re: TIDs info summary
- Subject: Re: TIDs info summary
- From: Richard Morton <email@hidden>
- Date: Sun, 10 Nov 2002 21:46:22 +1100
On Sunday, November 10, 2002, at 06:18 AM, bill fancher wrote:
...The fact that we can invisibly or unexpectedly alter tid's is the
result of a design decision. There were probably compelling reasons for
that decision but it creates pitfalls. Rather than constantly alerting
people to the ensuing dangers, the general consensus seems to be that
we should assiduously paper them over. That we should make it easy for
people to write buggy code and get away with it, and harder for them to
find their errors and learn from them.
That's certainly one aspect of the argument, and I agree that any
practice that hides coding errors is not good if that's all it does, but
there is another issue. In psuedo code:
set tids to someValue
set t to text items of someSting
repeat with n from 1 to count of t
if item n meets someCondition then
drop into handler that uses tids to process the item
else
whatever
end
end
continue with processing that relies on tids being set to someValue
If the handler does not restore tids, the subsequent processing will
break.
The principle is simply to not alter things that can have an affect
outside the handler. Not because somebody else might assume they're set
to the default, but because they may be in use already. This may have
the side effect of masking such assumptions, but it's not the reason for
doing it.
I really don't care what other people do with their tids, but I always
save/set/reset them because I think it's bad practice to change anything
outside the scope of the code. Not restoring them assumes that they're
not already in use and there may be times when this assumption is false.
For lazy tids users, I recently found the following construct & use it
in handlers where tids are changed repeatedly. There is no speed
overhead that I can detect & it saves a bit of typing:
tell AppleScript
set text item delimiters to...
...
end
Cheers,
Tex D'laminator
-- Great Questions of Modern Romance #6 "Are we an item or is this just
another empty string?"
_______________________________________________
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.