This page is part of the web mail archives of SRFI 64 from before July 7th, 2015. The new archives for SRFI 64 contain all messages, not just those from before July 7th, 2015.
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/