On Thu, Jul 30, 2009 at 6:36 PM, Barry
Leiba<barryleiba(_dot_)mailing(_dot_)lists(_at_)gmail(_dot_)com> wrote:
Require implementations to raise a compile time error when list
is used with an unsupported test.
That's already what happens when there are such errors in scripts.
Why should we say it explicitly here, and not everywhere else?
philosophically, i believe in full and complete specifications, with
any areas of variance clearly indicated
practically, as the draft 00 stands, i feel that an implementator
might reasonably elect to test the combination of test and match-type
at compile time, at run time or not verify the condition at all. my
strong preference would be to just issue a warning with an option for
raising a runtime error.
so, though my implementation preference would be excluded by this
proposal, at least the expected behaviour would be clearly specified
Implementations MAY support other tests but MUST raise a compile
time error when a script contains any standard test where support has
not been explicitly specified.
Not explicitly specified by whom? How?
yes - i'm not happy with the wholley language either
probably better just to specify those tests which should not be supported
How does this make scripts portable?
i'm a little confused by this
when a script contains an extension, it will only compile on engines
that support that extension. asking extensions to abide by the
description of list in this draft (if they support it) means that at
least that may be relied upon by the script writer.
This seems to encourage private
extensions, which has really become a thorn in the web.
an extremely controversial statement ATM (but i'm going to avoid
taking the bait)
happily, sieve is extensible so this philosophical question has
already been resolved in the original specification. i think that a
revision of RFC 5228 would be the right place to start for anyone who
disagrees with this fundamental design decision.
what needs to be decided by this working group is whether the group
thinks that list should work uniformly across all extensions
- robert