[Petal] Re: Using Test::More

[Fergal Daly]

On Thursday 10 April 2003 00:52, you wrote:
> > Yes, sorry I wan't too clear about that. try the following benchmark
> > <snip>
> 
> Right! Interesting. Well, I would have amended the CodeGenerator but 
> since you're doing it on what could be a drop-in replacement for the 
> CodeGenerator I might just do nothing :)

I've attached a patch for CodeGenerator.pm that removes all mention of @res 
from the vairous subroutines. Instead, whenever they want to add something to 
@res they call $class->_add_res($thing). This returns

"push \@res, $thing"

but I've also included CodeGeneratorString.pm which subclasses CodeGenerator 
and return

"$res .= $thing"

The improvement on my benchmark seems to be about 10% which is not so much 
really but there's no downside that I can see.

There's another patch attached. I made a silly mistake in 2 of 2 tests I 
changed. So here are all the test patches again, this time with no mistakes I 
hope. They should apply cleanly to 0.91.

> > The main difference is that I don't use the Petal hash, I just use an 
> > ordinary hash. I parse all the expressions beforehand so compile time
>  > is longer but then execution is speeded up a lot.
> 
> I see... So basically rather than having Petal::Hash::VAR evaluating 
> your expression you get the CodeGenerator to do it. Hum... interesting! 
> Maybe each modifier could have a as_perl() method that returns a do { 
> ... } block, so that nesting them would be trivial?

Modifier as in not:, false: and that sort of thing? That's basically what I do 
happens, so as you say nesting is easy. It also makes the pipe syntax 
relatively easy.

> Indeed if the code which is produced stayed indented that'd be ideal!

The code I produce is not indented at all! This can be changed though...

> This should be:
>      (UNIVERSAL::can($thing, "bar") || UNIVERSAL::can($thing, "AUTOLOAD")

I just typed my example up quickly. In the real code reality I'm doing exactly 
what you are, mainly because I based it on your code! Which reminds me, we 
both should be using Scalar::Util::reftype() to determine the base type of a 
reference.

ref($thing) =~ /=HASH/

will break with an object that using overloading to look like a string. 
Surprisingly, Scalar util seems to be faster too

use Benchmark;
use Scalar::Util qw( reftype );

my $ref = {};

my $ut = sub
{
  $a = (reftype($ref) == "HASH");
};
  
my $re = sub
{
  $a = ($ref =~ /=HASH/);
};
  
timethese(-5,
  {
    util => $ut,
    re => $re,  
  }
); 

re: 108835.76/s
util: 250873.11/s

> > As you can see it doesn't test for an ARRAY ref because the key was not 
> > numeric. If the key was numeric then it would replace the object test with 
an 
> > array test.
> 
> Smart...

You do it in your Var.pm too...

> And that's exactly the reason for which I use templates. I do _NOT_ want 
> them to look like Perl! Personally I love Perl syntax BUT I also think a 
> lot of people (esp. the ones who are writing / maintaing templates) 
> don't necessarily see it that way :)

Yep and I think TAL does it brilliantly. It has exactly the same goals as the 
template system I built for myself, except TAL actually achieves them!

F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: string.patch
Type: text/x-diff
Size: 6224 bytes
Desc: not available
Url : http://www.email-lists.org/pipermail/petal/attachments/20030410/a5f5c40b/string.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tests.patch
Type: text/x-diff
Size: 16027 bytes
Desc: not available
Url : http://www.email-lists.org/pipermail/petal/attachments/20030410/a5f5c40b/tests.bin