Actualy the speed difference has nothing to do with the evals. The evals are all done at compile time to do the overloading without 700 lines of code ;).
The difference is that you short ccircuit the logic operation so that it stops as soon as it knows the anser. Mine collects data and reports what items caused the failure.
A quick less than scientific benchmark using short circuiting speeds my code up to the point where yours is 350% faster still.. Which isn't bad but since the same benchmark was showing yours 1277% faster a second ago its not a bad speed up.
| [reply] |
if ( all(@foo) ) {...}
and have is evaluate the arguments for 'truth'. So I'll be adding that when I get a chance.
I don't think I'll be adding stringification overloading. I can't really explain why, but I really don't like print any(@foo) printing a random element. | [reply] [d/l] [select] |
The @{} lets you do my $large = any(1..10) > 5;my @large = @{$large}; That is why I don't short circuit. The stringification is something i went back and forth on. It might fit better as any(1..10)->string; but I dunno.
BTW I added in the arthimitic. The nice thing about the dynamic way I overload is that it was only a few extra lines of code.
my $mix = all(1..5) + any(1,2); produces a result like my $mix = all(any(2,3),any(3,4), any(4,5),any(5,6), any(6,7));
Operator overloading realy is magic. ;) I also added a regex ->match method which alls things like if (any(@strings)->match(all($regex))
| [reply] [d/l] [select] |
Aren't the math operators something like:
sub do_<op> {
my ($self, $other, $switch) = @_;
@$self = map {
$switch
? ($other <op> $_)
: ($_ <op> $other)
} @$self;
return $self;
}
The Perfect is the Enemy of the Good.
| [reply] [d/l] |