On Fri, Oct 21, 2005 at 01:07:53PM -0700, Ned Freed wrote:
On Fri, Oct 21, 2005 at 10:44:20AM -0700, Ned Freed wrote:
On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
I did wonder about that wording; seems to me that the the script as
a whole probably shouldn't fail, but the non-first vacation
action(s) should give an error. i.e. duplication vacation actions
should fail, not abort the entire script. (Not to mention that if
the script were to fail on the second "vacation" then there would be
no need to say "or more".)
I think this is an absolutely terrible idea.
Which idea do you think is terrible? Multiple vacations causing a script
to fail, or simply reporting an error on a multiple vacation?
The idea that multiple vacation action errors should be silently ignored
until the first non-vacation action is taken.
Ah. But that's a third case. Why would the first non-vacation action
cause an error? The context was whether in:
vacation :handle x "something"; # A
vacation :handle x "something"; # B
whether executing B causes the script to fail, or whether the script
continues past B (suppressing the execution of the B action, whether
noting an error or not). A later non-vacation action (in this case,
"fileinto") shouldn't cause an error whether there is one vacation
statement or two. So the example is still confusing to me.
Particularly the comment about the success of the test mattering, rather
than the multiple vacation actions being executed.
Hmm, going back again... perhaps you were reading my "non-first
vacation" as "non-vacation" ?
There is certainly precedent for suppressing duplicate vacation
actions. The base spec says (at least the way I read it, and thus the
way I implemented it) that multiple attempts to file into a folder will
be silently suppressed. See 2.10.3, which says:
> Implementations SHOULD NOT deliver a message to the same folder more
> than once, even if a script explicitly asks for a message to be
> written to a mailbox twice.
>
> The test for equality of two messages is implementation-defined.
>
> If a script asks for a message to be written to a mailbox twice, it
> MUST NOT be treated as an error.
I don't know the reasoning behind this, but I assumed it is to make it
convenient and harmless for a script writer to express their intent to
write a message into a particular folder when more than one test
succeeds. ("I twice intend to write into this folder" rather than "I
intend to write into this folder twice").
VIolations of the least
astonishment principle abound. Consider:
vacation whatever1;
vacation whatever2;
if test {fileinto blah;}
If the test fails the script appears to work, sending one vacation
response
but not the other. But if the test succeeds the script now fails for
reasons
having nothing to do with the test. Such a gotcha can remain hidden
indefinitely only to go off when you least expect it - a script landmine.
I still don't get that. Probably it's me. When you invoke the
principle of least astonishment, I find that that is accomplished by
making the vacation action work in the same way as fileinto, for the
same reason. And with duplicate vacation causing a failure, you get
that 'landmine' (which I would simply describe as a coding error) even
more with:
vacation whatever1;
if test { vacation whatever2; }
fileinto "blah";
since when the test fails, you get one vacation response and the message
filed into blah; if the test succeeds, you get a vacation response and
you do not get the message filed into blah (rather, the inbox). This
seems more along the lines of your view of a landmine; how is this
better?
The minute you have failure cases that don't report when encountered and
instead wait for some other condition to arise before becoming an error you've
got a mess on your hands.
I completely agree with that. What I don't understand is how it applies
to this particular point. (OTOH, unrelated to vacation, it could apply
in an implementation that defers actions.)
Yours,
-mm-