Re: Not strict

[diotalevi]

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 ....
}

[broquaint]

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

[Aristotle]

That won't work. It has to be

*{$GMPN::Database::Table::{"$_::"}{pre_insert}} = sub { ... };

Ok, I need some salt with that foot.

Makeshifts last the longest.

[allolex]

Take off your shoes and socks first. Feet are pretty damn salty---trust me on this one. ;-)

--
Allolex

[diotalevi]

Oh yuck, but that's some really ugly syntax. I'd definately prefer removing strict refs (locally) to using that syntax.

[Aristotle]

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.

[diotalevi]

Ok, so it was at least better. And thinking back, I initially wrote each glob access many lines apart which didn't lend itself to that expression.

[jonadab]

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"))};