On Tue, Jan 20, 2009 at 1:08 PM, Moritz Lenz <mor...@faui2k3.org> wrote:
> So Larry and Patrick developed the idea of creating an > adverb on the test operator instead: > > $x == 1e5 :ok('the :ok makes this is a test'); > > This is an adverb on the infix:<==> operator, and might > desugar to something like this: > > multi sub infix:<==>($left, $right, :$ok) { > $*TEST_BACKEND.proclaim($left == $right, $ok) > or $*TEST_BACKEND.diag( > "Got: «$left.perl()»; Expected: «$right.perl»"); > } > > (Daniel Ruoso also proposed to call the adverb :test > instead of :ok, making it easier to read but a bit > longer; my happiness doesn't depend on the exact name, > but of course we can discuss it once we have settled > on this scheme, if we do so). I like this idea and with it built into the language itself, there will be much less of an excuse to skip testing. I like the adverb form, which seems more perl6 than C. Naming it something like :test is a better idea than :ok as that seems a bit more direct. There isn't much in the spec concerning namespaces, other than the default * namespace. Is there any reason why the testing framework can't go in it's own namespace? > * We nearly double the number of built-in operators > by adding an :ok multi > * We force implementors to handle operator adverbs > and named arguments very early in their progress > (don't know how easy or hard that is) > * Testing of operators becomes somewhat clumsy. If you > * want to test infix:<==>, you won't write > '2 == 2 :ok("== works")', because you test a > different multi there. Instead you'd have to write > something like '?(2 == 2) :ok("== works")', where > :ok is an adverb on prefix:<?>. > These are mostly disadvantages to implementors, not users of the testing framework. I'd rather the implementations struggle to implement a built-in testing functionality than users of the language struggle to use the built-in testing. > I'll send another mail on the subject of pluggable > testing backends in order to allow different emitters > (TAP output, storage into databases, whatever) This is a requirement for me. Having only TAP emitters may not integrate well. It would be nice if the spec, if added, would allow flexibility in this realm. I would actually like to see a flexible system that allowed me to define a new emitter, say for the cases where you want to integrate perl6 testing into an existing testing framework (think automated builds and tests). -Jason "s1n" Switzer