On Thu, Jan 12, 2006 at 03:22:59PM -0500, Barry Leiba wrote:
If I should move that script to a system that doesn't support
notify, I might still want it to "work", in that I'd want it to do
everything except the pager bit.
Ok, so the focus of this new test, whatever we call it, is to enhance
script portability. I use Sieve in a number of places, but all scripts
are so different that portability is the least I would think of.
Your applications are obviously very different.
then I get what I want, and I don't have to change the script. And if,
some say, my system adds support for notify, I'll start getting paged
without having to find out that it's been upgraded, and without having
to put the notify code back into the script.
Not something I would like. Out of a sudden previously dead code
gets active. My phone number might have changed and now someone else
gets my notifications (my fault). There may be a semantic mistake in
the previously dead code, something managesieve could not check before,
and now that it is active, it causes an error and my script terminates,
leaving a mess to be discovered when coming back from vacation.
To me, we are talking about two different issues, and "environment"
as we talk about it, combines them in an unfortunate way. I prefer to
put different things in different extensions:
o Getting to know which extensions are supported. For your applications,
a Sieve extension is useful. For mine, something like managesieve,
although I would never implement it, is more suitable. Ok, I see no
problem there. "environment" may be good solution for Sieve and
any sieve implementation certainly had no problem to support that.
o Having a way of not letting unknown extensions cause script failure.
But why restrict that to unknown extensions? How about exception
handling, something like "try & catch"? That does not only catch
semantic errors at the action level, but also at the argument/option
level. Your "if" test above only catches the first.
I don't think I need either, but a new extension that looks like a
test and requires the fundamental change from strict to somewhat lazy
error checking sounds very wrong to me. Exceptions may not be the best
solution, but at least you expect them to change error handling, and
they do so universally.
Unfortunately, the case spec forbids:
try { require "notify"; } catch { }
The "require" statement is only allowed at the beginning of scripts.
Too bad.
Michael