Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Just another Perl shrine
 
PerlMonks  

Re: Re: Re: A Perl aptitude test

by BrowserUk (Pope)
on May 03, 2003 at 09:41 UTC ( #255289=note: print w/ replies, xml ) Need Help??


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

An interesting variation on the theme might be to ask when they would consider not using strict.


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.


Comment on Re: Re: Re: A Perl aptitude test
Not strict
by crenz (Priest) on May 03, 2003 at 10:56 UTC

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

      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.

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

        _________
        broquaint

        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.

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

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

Re: Re: Re: Re: A Perl aptitude test
by marinersk (Chaplain) 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.

      I'm probably misunderstanding your description as I couldn't create the error you describe, but maybe you were using an earlier version of Perl?

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://255289]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (11)
As of 2014-04-18 14:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (469 votes), past polls