[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Static ambiguities: test-end and test-apply
On Wed, 23 Mar 2005, Per Bothner wrote:
> Donovan Kolbly wrote:
> > In general, I don't care as much about the order of arguments, but I do
> > find it's better to ascertain the meaning of an invocation with no more
> > work than counting the number of arguments (i.e., not having to examine
> > the type of the arguments).
> I'm used to Java (and C++) overloading so I may have more tolerance for
> selecting depending on argument types.
Ah, sure. Doesn't Java have a problem with static ambiguity as well?
That is, like C++, it dispatches based on the static type and not the
dynamic type (except for the receiver "this" argument).
Anyway, it seems like overkill for me to define a generic for these, and
usually I want to implement them as syntax (so I can capture compile-time
info like line numbers) which adds another indirection.
Well, it's tractable, just inconvenient.
> > In the current spec, test-end is ambiguous:
> > (test-end [name] [count])
> I'm thinking about moving the count to the test-begin. That might be
> helpful for a test-runner that displays a progress bar, for example:
I like it!
> (test-begin name [count])
> (test-end [name])
> But in that case should test-group also have a count?
> (test-group name [count] form ...)
Probably so, for consistency. More static ambiguities, though...
> > as is test-apply:
> > (test-apply [runner] specifier ... thunk)
> > Furthermore, if test-apply were made to require the runner (the user could
> > supply (test-runner-current) if needed), this would also solve the
> > "implicit runner" problem (*).
> No objection to making the runner non-optional - it's not like
> people will be writing lots of test-apply calls.
That was my thinking as well. So let it be said, so let it be done.
> > (*) The "implicit runner" problem: there are currently two forms which
> > can implicitly create a runner: test-begin and test-apply. It's obvious
> > how to "finalize" (bring about the invocation of the on-final hook) one
> > created by test-begin, but it's less clear how that should happen for
> > test-apply. In fact, this is a real problem for my current
> > implementation!
> If test-apply creates a new runner, then it should also finalize it.
> Just like test-group/test-begin+test-end do. Am I missing something?
That would work great. It just wasn't clear from the spec what was
intended. Consider my implementation and test suite so adjusted.
> It probably is convenient to have a short-hand to run a specific set of
> tests with a default runner being created and finalized. The use case
> I'm thinking of debugging a test-suite or a specific test.
That makes sense. So far, I've only been running complete suites, even
while debugging specific tests, but you would definitely want that.
-- Donovan Kolbly ( d.kolbly@xxxxxxxxxxx