[JOB] Perl Software Developer and Database programmer

[Tim Sweetman]

Lusercop wrote:

>On Wed, Feb 22, 2006 at 05:39:50PM +0000, Andy Armstrong wrote:
>  
>
>>On 22 Feb 2006, at 17:08, Lusercop wrote:
>>    
>>
>>>In which case, why are you needing to localise it? Any situation where
>>>you need to localise it means that the scope of it is too large.
>>>      
>>>
>>it's nice to be able to write subs that look map or grep - which  
>>means not trashing $_.
>>    
>>
If you have to do something like this:
local $_ = 'house'; # tell the wolf what to blow down
Bad::Wolf::BlowDown("very forcefully");

... then that's passing parameters via $_, and is obviously a ghastly 
hack and silly, and should cause maintenance programmers to shout, a 
lot, and rudely.

On the other hand, localising $_ from inside a function, so that 
function can be called without tipping over the caller's $_, does no 
damage to the program's structure. In fact, Lusercop seems to be 
criticising a function for NOT using global variables.
And that's ridiculous.

>
>But not necessary. And the hacks to do it can sometimes be not worth the
>pain.
>
>  
>
>>>I'd humbly suggest that this "makes the code more fragile", but perhaps
>>>I'm just talking as someone whose main commercial programming experience
>>>up to a year ago was maintenance programming.
>>>      
>>>
>>This from the man who suggested faking |local| using |my| and ended  
>>up with less robust, more obscure code :)
>>    
>>
>
>Er, no. I suggested not using globals, but if you absolutely HAD to use
>globals then doing it explicitly. And I think it's less obscure.
>  
>
Actually, you said

>I can
>imagine a very good software engineer who doesn't understand the difference
>between [local and my], because he's never had to use local, all his/her code is
>reentrant and doesn't use globals which need localising.
>
Which is fair enough. Minimise coupling. That's why we aren't using BBC 
Basic, right? Though that last bit could be read as either (a) "has no 
global variables at all, so using 'local' is unnecessary and useless", 
or (b) "doesn't use any globals which would cause strange interactions 
during re-entrancy, so there are globals in it but 'local' is 
unnecessary". I suspect you meant (a), but that's with hindsight.

THEN, you said:

>If, on the other hand, you want a software
>engineer, then a candidate knowing that local exists and that it's almost
>always the wrong answer is still in the running. As I said elsewhere in
>this thread. (and given that you can simulate the effects of local with a
>more explicit set of mys, in a much clearer way, then this is also true).
>
The "much clear way" turned out to be:

>{
>   my $newdollarslash = "whatIwant";
>   my $savdollarslash = $/;
>   $/ = $newdollarslash;
>
>   dostuffwithappropriatecalls();
>
>   $/ = $savdollarslash;
>}
>


Andy then described you, the lusercop, as "the man who suggested faking 
|local| using |my| and ended  up with less robust, more obscure code".

To which lusercop says:

>Er, no. I suggested not using globals, but if you absolutely HAD to use
>globals then doing [so] explicitly [by shunting values into 'my' variables].
>
That's "yes", not "no".

FWIW, Damian Conway's "Perl Best Practices" (Chapter 5, p. 77) says:
"If you're forced to modify a package variable. localize it... 
Occasionally you will have no choice but to use a package variable, 
usually because some other developer has made [it part of a module's 
interface... using local is a much more neighbourly approach than 
setting your value & leaving it]".

HTH

ti'