Perl Software Developer and Database programmer

On Wed, Feb 22, 2006 at 04:54:58PM +0000, Andy Armstrong
wrote:
> On 22 Feb 2006, at 15:27, Lusercop wrote:
>> Seriously, I hope you're not suggesting that full
use of $_ with
>> localisation is good software engineering practice
when programming
>> in Perl. I really hope you're trolling.
> No, I'm not trolling. I use $_ whenever I feel its use
is clear and  
> won't make the code significantly more fragile.

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.

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.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

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.

Recently, something like this:

#!/usr/bin/perl

sub bof (&);

$_ = 'Hello, World';

bof {
     print "*** $_ ***\n";
} qw(One Two Three);

print "$_\n";

sub bof (&) {
     my $cb = shift;
     for my $x (_) {
         local $_ = $x;
         $cb->();
     }
}

That's a contrived example - if it was that simple the loop
in bof  
could be rewritten as

     for (_) {
         $cb->();
     }

and $_ would automatically be localised. In less trivial
cases though  
it's nice to be able to write subs that look map or grep -
which  
means not trashing $_.

> 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 

-- 
Andy Armstrong, hexten.net

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

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.

Perlfaq would seem to agree with me, in general.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

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'

Tim Sweetman wrote:
[point by point rebuttal of lusercop snipped]

You do know lusercop gets £0.001 for every K sent on the
l.pm mailing 
list, right? You do also realise you'll never get the five
minutes it 
took you to write back again, right?

Go eat a carrot[0] instead of feeding the troll in future.

   n

[0] Not a euphamism. I recently stopped smoking cigarettes
and gained a 
carrot addiction instead. *sigh*

Nigel Rantor wrote:
> Tim Sweetman wrote:
> [point by point rebuttal of lusercop snipped]
> 
> You do know lusercop gets £0.001 for every K sent on
the l.pm mailing 
> list, right?

But the l-pm would not be the same without him 

Jacqui

On Wed, Feb 22, 2006 at 11:47:36PM +0000, Nigel Rantor
wrote:
> Tim Sweetman wrote:
> [point by point rebuttal of lusercop snipped]
> You do know lusercop gets £0.001 for every K sent on
the l.pm mailing 
> list, right? You do also realise you'll never get the
five minutes it 
> took you to write back again, right?

I wasn't trolling. Ti' knows exactly who I am, and how I
think. I worked
with him for several years.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

On Thu, Feb 23, 2006 at 11:05:20AM +0000, Jacqui Caren
wrote:
> But the l-pm would not be the same without him 

Or without your crass comments, Jacqui.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

On Wed, Feb 22, 2006 at 11:28:41PM +0000, Tim Sweetman
wrote:
> 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.

Yup, indeed.

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

No, I'm criticising the function for using LOCALISED
globals. I do see
these as a special case of global variables, which is where
I think Andy
and perhaps you, and I differ. To try and find the
localisation at what
might be several levels above makes them effectively global
as far as I
am concerned.

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

Yes, I meant (a). Though even using $_ in a tight context is
fine and hence
(b) is also true.

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

No it's not. The main thrust of what I've been saying is
"don't use global
variables at all", which Andy, Peter Corlett and
others have chosen to
ignore. Instead they've been picking holes in me suggesting
that a perl
programmer didn't actually have to know about local because
one could
 "fake local using my", which, actually, I
happen to think is a clearer
indication of what is going on, but...

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

That's reasonable advice, and I'm not going to dispute it.

If you want to still think I'm trolling, that's up to you.
Your loss.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

Lusercop wrote:
> On Thu, Feb 23, 2006 at 11:05:20AM +0000, Jacqui Caren
wrote:
> 
>>But the l-pm would not be the same without him 
> 
> 
> Or without your crass comments, Jacqui.

I meant it - you often say something that I was thinking.
I do not agree with everything you say but does anyone?

Jacqui