Re: Not strict
by diotalevi (Canon) on May 03, 2003 at 15:10 UTC
|
When using strict would violate the "once and only once rule". Consider the difference between specifying a whole series of package names versus interpolating something in.
*GPMN::Database::Table::org::pre_insert =
*GPMN::Database::Table::user::pre_insert =
..... # repeat for another 15 tables and then do the same for ::pre_up
+date
for (qw[org user group foo bar]) {
no strict 'refs';
*{"GPMN::Database::Table::${_}::pre_insert"} = sub ....
*{"GPMN::Database::Table::${_}::pre_update"} = sub ....
}
| [reply] [Watch: Dir/Any] [d/l] |
|
But that is more laziness than necessity e.g
use strict;
...
$GMPN::Database::Table::{"$_::"}{pre_insert} = sub { ... };
Really must get around to writing that meditation on how one essentially never needs to turn off strictures.
HTH
_________ broquaint | [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] [d/l] |
|
|
| [reply] [Watch: Dir/Any] |
|
That is what you call doing it once and only once?
my $namespace = \%GMPN::Database::Table::;
my %inject = (
pre_insert => sub { ... },
pre_update => sub { ... },
);
for my $subpkg (qw[org user group foo bar]) {
my ($method, $code);
$namespace->{"$subpkg::"}->{$method} = $code
while ($method, $code) = each %inject;
}
Makeshifts last the longest. | [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] |
|
That's very similar to a situation I was thinking about,
except that I would have stated it more generally: I
would consider (locally) using symbolic references in
a scenerio when they would be convenient and the risk
would be checked by having the complete list of possible
values of the reference ennumerated en toto in the code.
Additionally, I never bother with strict for very short
use-once scripts (e.g., anything I type at the command
line after perl -e).
Truthfully, I don't always use strict in other cases
either, but I'm starting to do so more often that I
used to do. I'm up to the point of using at the top
of all files that get included by another file now,
which is progress... and for the record I have yet
to see strict catch a mistake that warnings missed,
except in a conversation on Perlmonks where a monk
contrived an example for me to demonstrate how it
could happen. However, the example (though contrived)
was sound and I've taken it to heart somewhat.
And that's why I don't think question 2 as it stands
will get the information the test writer actually wants.
I would have no trouble explaining the value of strict
at this point, but I don't yet have a firm habbit of
always using it, which is what the test really wants
to know. (The best way to find out? Have 'em write a
section of code to do some simple task and see if they
declare all of their variables.)
Actually, my biggest problem with strict is that it
doesn't test what I want it to test: whether a
subroutine tromps on a (possibly lexical) variable
from outside the subroutine. This is for me a *way*
more likely scenerio than the ones strict does check.
{my$c;$ x=sub{++$c}}map{$ \.=$_->()}map{my$a=$_->[1];
sub{$a++ }}sort{_($a->[0 ])<=>_( $b->[0])}map{my@x=(&
$x( ),$ _) ;\ @x} split //, "rPcr t lhuJnhea eretk.as
o";print;sub _{ord(shift)*($=-++$^H)%(42-ord("\r"))};
| [reply] [Watch: Dir/Any] [d/l] |
Re: Not strict
by tilly (Archbishop) on May 17, 2003 at 21:50 UTC
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
The rules in question were rules for good programming practices, sometimes Perl specific (eg using strict), and sometimes not (eg avoid goto). If you break these rules, Perl won't hunt you down and kill you, but your maintainance programmers might. :-)
| [reply] [Watch: Dir/Any] |
Re: Not strict
by BrowserUk (Patriarch) on May 03, 2003 at 11:23 UTC
|
Short answer: Extremely rarely.
Slightly longer answer:
If my application ran/tested cleanly with use strict, but the operational requirements were such that disabling it allowed those ORs to be met without further modification, when they were not met when it was in force.
Supplimentary question: Under what circumstances might this scenario be so?
My answer: I have yet to encounter one, but if I did, I would consider the option.
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] [Watch: Dir/Any] |