Not strict
by crenz (Priest) on May 03, 2003 at 10:56 UTC
|
| [reply] [Watch: Dir/Any] |
|
*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] |
|
|
|
|
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] |
|
|
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] |
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
|
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] |
Re: Re: Re: Re: A Perl aptitude test
by marinersk (Priest) on May 15, 2003 at 15:40 UTC
|
In my extremely limited experience with Perl, I've only run into one place where I couldn't use strict; I had a module that was tracking multiple file locks using flock() and I was storing the various file handles in a hash. When I tried to close the files (and thus release flock()'s lock) I got an error about "using string substitution for symbolic table entries under strict" or some such thing. So I commented out the use strict; line and documented why, and forced that set of functions into its own module, never to be mingled with others.
So, I suppose, implicit in this story is that, for now, I wouldn't not use strict; unless it was required.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
use strict;
open FH, '<', 'test1.dat' or die $!;
my %h; $h{FH}=FH;
flock( $h{FH}, 2);
close $h{FH}
That said, the only critisism of your approach I would have, and it's only from the "if your going to use strict, use it everywhere possible" point of view, is that as strict is lexically scoped, you can usually get away with something like
....
{
no strict 'refs';
# do the thing that conflicts with strict.
}
....
Which retains as many of the benefits of strict as possible for as much of the code as possible and adds an element of self documentation, which you could always add to if necessary. In your case, it would also remove the need for a seperate module if that meant an abitrary split in codebase.
To date, I haven't found a single time when I've wanted to drop strict, even at very localised level. Perhaps because every program I write starts life as a template that includes it. Maybe because I've never been a shell programmer and never used Perl before v5.6. Whatever the reason, I never even find myself going out of my way to avoid dropping it. The issue just never seems to come up. Then again, I think I've only used eval 2 or 3 times.
Maybe there is a whole world of simple, elegant solutions to difficult problems that I'm missing out on, but for now I'm happy in my ignorance of them:)
All of that said. If I ever encounter a situation where I needed to drop strict (locally), I wouldn't hesitate to do so if it made sense, especially if it avoided a convoluted work-around.
In essence, I agree with your answer:)
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
I am saddened to see I never got around to thanking you for this post.
As a consequence of your reply, I learned that strict was lexically scoped, as well as the syntax for how to release its iron grip, as well as the idea that one could reduce only pertinent portion of its iron grip and the synxtax thereto, resulting in this snippet which was no longer relegated to its "quarantine module":
# If it's our last lock, release it.
if (!$lckcnt) {
# It's our last lock. Release the lock token file.
my $lckfnm = &_getLockFilename($filfnm);
{
# Must disable warnings and strict for this
no warnings;
no strict;
close $Lckhan{$KEY_LCKHAN}{$filfnm};
}
}
So, as many times before, thanks for having taken the time to write this -- OMG -- ten years ago.
| [reply] [Watch: Dir/Any] [d/l] |
|
|