[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
				     (  http://www.rscheme.org/~donovan/