[JOB] Perl Software Developer and Database programmer
`the.lusercop' at lusercop.net
Thu Feb 23 11:21:17 GMT 2006
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.
> 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
> 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'
> 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
More information about the london.pm