On 30 Nov 2007, at 00:25, Eric Wilhelm wrote:
Aha. I see; those were examples that hadn’t come up before. So
ordering is useful to avoid an explosion of options.
Or ... WE COULD HAVE AN ORDERING OPTION PARSER!
SPEAK UP.
We could, indeed, have an ordering option parser. But I suspect
ordered options are less easy to grok than a string that is explicitly
a query the ordering of whose elements are significant.
I've just added slow and fast options - so you can run the tests
slowest to fastest or fastest to slowest. That's useful in conjunction
with -j because it ensures parallel runs kick off with the slowest
test avoiding the situation where you slow test happens to run last
and you lose some of the benefit of parallel testing.
So would you really have me add two more switches to prove's top level
interface?
The state engine has a fairly general mechanism for building queries
from lists of terms - it seems wrong to couple that tightly to prove's
UI by exposing each element of its syntax as a top level switch.
Sorry for the yelling, this one just happens to tickle my yelly-bone.
Well quite. But I see it as pretty much orthogonal to the question at
hand. If we decided to go with top level switches to control the state
engine we'd cross the option ordering bridge. But I simply don't think
it's a good idea. As I write there are nine different options that can
be passed to --state. Already that would be a lot of pollution in
prove's already fairly crowded UI. How is it not better to keep all of
those options in the --state namespace? It makes the documentation
clearer, the UI easier to remember, the code easier to maintain.
Have you tried it?
--
Andy Armstrong, Hexten
