Steve Bertrand wrote:
> However, I needed to take two seconds to at least state that my claim,
> that the second param into Test::More "is forced into qr//" was
> unfounded and unjustified.
>
> I don't know if that is what happens
For completeness (and as a code tracking exercise for myself),
Uri Guttman wrote:
>> "SB" == Steve Bertrand writes:
> >> again, what is unlike? i now guess it is from a test module. does it
> >> take a regex as an arg?
>
> SB> unlike is from Test::More. Both unlike and like take a regex as it's
> SB> second parameter. I took a quick look at the
> "SB" == Steve Bertrand writes:
SB> Uri Guttman wrote:
>>
SB> for my $known_type (@known_types) {
>>
SB> unless (exists $typedefs{$known_type} ) {
>>
>> again, you don't need exists there. since your dispatch table's values
>> are always code refs so they will always be tr
Uri Guttman wrote:
>> "SB" == Steve Bertrand writes:
>
> SB> In all honesty, I think I'm learning more about Perl (and my own
> SB> programs) writing the tests than I do when I'm writing the programs
> SB> themselves. (Same goes for keeping up with the documentation!).
>
> coding is co
> "SB" == Steve Bertrand writes:
SB> In all honesty, I think I'm learning more about Perl (and my own
SB> programs) writing the tests than I do when I'm writing the programs
SB> themselves. (Same goes for keeping up with the documentation!).
coding is coding and the more you do the mor
Uri Guttman wrote:
>> "SB" == Steve Bertrand writes:
>
> SB> I create %typedefs hash, where each key is a name which has a value of a
> SB> coderef that simply creates and returns a hash. Then:
>
> SB> my @data_types = $vardb->is_type();
> SB> my @missing_types;
>
> SB> for (@data
> "SB" == Steve Bertrand writes:
SB> I create %typedefs hash, where each key is a name which has a value of a
SB> coderef that simply creates and returns a hash. Then:
SB> my @data_types = $vardb->is_type();
SB> my @missing_types;
SB> for (@data_types) {
use named vars instead of
Shawn H. Corey wrote:
> Steve Bertrand wrote:
>> I also really like your suggestion of putting the hashes within a sub.
>> This will prevent the reset of ALL the data types each time new tests
>> are run.
>>
>
> You may want to look at dclone() from Storable. It clones deeply nested
> structures.
Steve Bertrand wrote:
I also really like your suggestion of putting the hashes within a sub.
This will prevent the reset of ALL the data types each time new tests
are run.
You may want to look at dclone() from Storable. It clones deeply nested
structures.
#!/usr/bin/perl
use strict;
use w
Uri Guttman wrote:
>> "SB" == Steve Bertrand writes:
>
> SB> I make these hashes available globally, initially as undef. I have a
>
> there is no such thing as an undef hash. it is either empty or
> not. undef is a single value and hashes are always in pairs. never do
> undef %hash or even
> "SB" == Steve Bertrand writes:
SB> I make these hashes available globally, initially as undef. I have a
there is no such thing as an undef hash. it is either empty or
not. undef is a single value and hashes are always in pairs. never do
undef %hash or even worse %hash = undef (the latter
Hi everyone,
In the test files I have that are used for testing the properties and
qualities of a data/type validator,
I make these hashes available globally, initially as undef. I have a
reset() function that defines and populates the data types (all hashes)
to a default state with default value
12 matches
Mail list logo
