in reply to Re: Re: Re: A Perl aptitude test
in thread A Perl aptitude test

Hmm... that's an interesting question. So when would you?

Replies are listed 'Best First'.
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 .... }
      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.


        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.

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

      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.

        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.

      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 o";print;sub _{ord(shift)*($=-++$^H)%(42-ord("\r"))};
Re: Not strict
by tilly (Archbishop) on May 17, 2003 at 21:50 UTC

      I didn't think perl had _rules_, just warning signs? Leastwise, that's what I read in perldoc and the Camel.

        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. :-)
Re: Not strict
by BrowserUk (Pope) 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.