Re: Tid's 'n AS
Re: Tid's 'n AS
- Subject: Re: Tid's 'n AS
- From: email@hidden (Michael Sullivan)
- Date: Wed, 6 Nov 2002 09:39:49 -0500
- Organization: Society for the Incurably Pompous
bill fancher writes:
>
Nice day for a flame war (with apologies to the originator of of the
>
phrase "tid's 'n AS", whose identity I've forgotten, but whose legacy
>
lives on)...
>
A fundamental tenet of defensive programming can be boiled down to
>
"Don't make unwarranted assumptions."
That's one of them.
>
Here's a script:
>
set abc to text items of "abc"
>
set c to item 3 of abc
>
The above makes an unwarranted assumption about tid's. To code
>
defensively, you'd write:
>
>
set text item delimiters to ""
>
set abc to text items of "abc"
>
set c to item 3 of abc
>
>
That will NEVER error (assuming AS itself isn't broken.) Perhaps good
>
programming rules say "every handler will restore tid's to the value
>
they had on entering the handler", but people don't always follow
>
rules, and the code they write doesn't either. Such a "good programming
>
rule" has no empirical basis. It's a PREscription, not a DEscription.
>
In the real world, people screw up. You can assume they won't and get
>
burned from time to time, or program defensively.
Another fundamental tenet of defensive programming is to assume your
users (including programmers who use your functions) could make any
*reasonable* assumption, even though they shouldn't, and make it work
they way they would expect unless there is a non-trivial cost to doing
so.
>
I NEVER "restore" tid's. I laugh at the tid's police. I'm a terrible
>
person, I WON"T change my despicable ways, and my code is coming to get
>
you. Be careful out there.
Here's the thing. The two rules go hand in hand. If you only do one
side, then any time you make a mistake, you (or somebody) gets burned.
If you always set *and* restore, then if you forget once, it *doesn't*
break.
There's a very clear design philosophy here, it's the same as the one
behind double entry accounting. The idea is that you have to make a
mistake *twice* for it to propagate and become a problem.
Make sure that what you send out to another program is a clean as
feasible, and make sure that what you *accept* from another program can
be a dirty as feasible.
This way *both sides* have to make a mistake for there to be any
problem.
If you only hold one side's hand to the fire, and give free reign on the
other, then anytime that side makes a mistake, it breaks something.
So I disagree with your despicable ways. You can do whatever you want,
as long as no one else has to work with your code. But as soon as
someone else does, a general practice of *both* setting *and* restoring
TIDs, is more likely to keep TID problems away.
Michael
_______________________________________________
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.
| References: | |
| | >Tid's 'n AS (From: bill fancher <email@hidden>) |