Re: Tid's 'n AS
Re: Tid's 'n AS
- Subject: Re: Tid's 'n AS
- From: bill fancher <email@hidden>
- Date: Wed, 06 Nov 2002 21:14:47 -0800
On Wednesday, November 6, 2002, at 06:39 AM, Michael Sullivan wrote:
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.
Assuming some value for tid's (e.g. "") is NOT reasonable.
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.
I call that "finding a bug". It lets you (or somebody) correct the
mistake.
If you always set *and* restore, then if you forget once, it *doesn't*
break.
Because you've masked the bug and left it lurking. It SHOULD break. The
sooner the better.
There's a very clear design philosophy here, it's the same as the one
behind double entry accounting.
Not at all. Double entry bookkeeping reveals errors, it doesn't hide
them. If you only make one mistake, the books won't balance. Making two
mistakes could conceivably hide the error: the exact opposite of what
happens when "restoring" tid's.
The idea is that you have to make a
mistake *twice* for it to propagate and become a problem.
"Restoring" tid's obscures the fact that other code may be buggy
precisely BECAUSE you then have to make two mistakes to trigger the
bug. And it allows someone else to make the second mistake for you,
probably at the worst possible time, if Murphy is to be believed.
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.
The only "side" whose code will break is the one that uses tid's
without setting them. Doing that is a BUG in your code. It's waiting to
be triggered, and conscientiously "restoring" tid's prevents you from
finding it.
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.
It doesn't prevent problems. It just postpones them. I prefer catching
bugs during development. Not "restoring" tid's makes that much more
likely.
If you use my code it will reveal bugs in yours. If I use your code, it
will hide bugs in mine.
Which one of us is doing the other a favor?
--
bill
_______________________________________________
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.