>>>>> "SB" == Steve Bertrand <st...@ibctech.ca> 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 true.
SB> ...my thoughts there were to catch a situation where I've added a new
SB> data type globally (within the context of the program), but it is not
SB> being tested within this test file, because a test definition hasn't yet
SB> been added. Will "exists" not catch that?
exists is a special hash test as a normal boolean test can't tell the
difference between a key with the value of undef or a missing
key. exists only checks the key and not the value so it was added for
that reason. in a typical dispatch table (and many other types of
hashes) all the values will be defined and even true (as in this
case). so you can just test for boolean and save some work. note that if
you grab the code ref like i showed you and then tested you could only
test for boolean (or defined) but not exists. but you only need a simple
boolean test. either you have a code ref for the key or you don't. and
code refs (as are all refs) are always true.
SB> push (@missing_types, $known_type);
SB> next();
SB> }
>>
SB> %data = &{ $typedefs{$known_type} };
>>
>> you didn't get my point about redundancy. $typedefs{$known_type} is used
>> twice which is once too many. if you refer to a hash value (especially
>> deep hashes) more than once, it is usually better to grab it into a
>> scalar and use that. it will likely be faster (saves hash lookups), it
>> is shorter (removed duplicate code) and is usually less bug prone as you
>> one have the expression (which can be complex) in one place.
SB> I get it, I get it! I finally see what you mean by that.
sometimes it takes a little hammering on your head to get it! :)
SB> eval { $sanity->check_type( $known_type, \%data, $error ) } ;
>>
SB> unlike ( $@,
>>
>> 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 docs, and the regex is
SB> forced into qr//, which would explain why my '$_' from the previous post
SB> was interpolated properly.
SB> '/not a defined datatype/',
>>
>> that isn't a regex, just a plain string with / chars on the ends. maybe
>> the unlike call will convert that but the / will be literal / chars. use
>> qr// or maybe the string without /.
SB> Yep, see above.
sounds like a poor design if it interpolates $_ to its value. that
implies string eval. and your using // there seems to be wrong
anyhow. but i don't know the unlike call so i can't say for sure. i
would pass a qr// anyway to be sure.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
