> Bryan R Harris wrote:
>>> Bryan Harris wrote:
John W. Krahn wrote:
> Bryan Harris wrote:
>> ... but by modifying $_ I was clobbering $_ elsewhere in the larger
>> program!
> Yes because $_ is a special global variable. This effect is called
> "action at a distance" whic
On Tue, Jul 28, 2009 at 16:12, Chas. Owens wrote:
snip
> I actually find the new style annoying. The floating toolbar obscures
> part of the doc, especially when you use a target like
> #Temporary-Values-via-local().
snip
Note, you can fix this behavior by going to
http://perldoc.perl.org/prefere
On Tue, Jul 28, 2009 at 13:11, Bryan R
Harris wrote:
snip
> Wow, I wish I'd read this email before sending that last one. The
> perldoc.perl.org site has gotten a tremendous upgrade, it's beautiful now.
> It also explains the whole local($_) thing, though it doesn't really explain
> "why", just "t
On Tue, Jul 28, 2009 at 15:50, John W. Krahn wrote:
snip
> local() only works on variables that are in the symbol table, in other words
> package variables. All variables that are a single puntuation character are
> package variables and some are global and effect all packages. local() does
> not
Bryan R Harris wrote:
Bryan Harris wrote:
John W. Krahn wrote:
Bryan Harris wrote:
... but by modifying $_ I was clobbering $_ elsewhere in the larger
program!
Yes because $_ is a special global variable. This effect is called
"action at a distance" which is why it is better to use named lex
On Tuesday 28 July 2009 20:06:34 Bryan R Harris wrote:
> > Bryan Harris wrote:
> >> John W. Krahn wrote:
> >>> Bryan Harris wrote:
> ... but by modifying $_ I was clobbering $_ elsewhere in the larger
> program!
> >>>
> >>> Yes because $_ is a special global variable. This effect is call
Bryan R Harris wrote:
Curiously, perlvar seems to recommend localizing $_ with "local", but I
thought I read somewhere to never use local and only use my. I still don't
understand how those two are different.
'my' variables are lexically scoped, that is, you can only use them in
the block or
> On Mon, Jul 27, 2009 at 09:49, Bryan Harris wrote:
> snip
>>> Yes because $_ is a special global variable. This effect is called
>>> "action at a distance" which is why it is better to use named lexically
>>> scoped variables instead of $_.
>>
>> I have the Perl Bookshelf on CD (and perldoc,
> Bryan Harris wrote:
>>
>> John W. Krahn wrote:
>>>
>>> Bryan Harris wrote:
... but by modifying $_ I was clobbering $_ elsewhere in the larger
program!
>>> Yes because $_ is a special global variable. This effect is called
>>> "action at a distance" which is why it is better t
On Tue, Jul 28, 2009 at 11:05, John W. Krahn wrote:
snip
> Perl 5.10 is still at the .0 stage (5.10.0) and a lot of people like to wait
> until software has progressed past the .0 phase.
snip
The good news is that 5.10.1RC1 looks like it will be released
shortly, so 5.10.1 will be here soon.
--
John W. Krahn wrote:
Perl 5.10 is still at the .0 stage (5.10.0) and a lot of people like to
wait until software has progressed past the .0 phase.
Actually it has more to do with hate than like, as in, "I hate things
that create more work for me."
It ranks right up there beside, "I have
Bryan Harris wrote:
John W. Krahn wrote:
Bryan Harris wrote:
... but by modifying $_ I was clobbering $_ elsewhere in the larger program!
Yes because $_ is a special global variable. This effect is called
"action at a distance" which is why it is better to use named lexically
scoped variab
On Mon, Jul 27, 2009 at 09:49, Bryan Harris wrote:
snip
>> Yes because $_ is a special global variable. This effect is called
>> "action at a distance" which is why it is better to use named lexically
>> scoped variables instead of $_.
>
> I have the Perl Bookshelf on CD (and perldoc, obviously) -
>> For example, my temptation was to do this:
>>
>> **
>> sub isDate {
>>
>> $_ = shift;
>> if (m!\d{2}/\d{2}/\d{2}!) { return 1; }
>> else { return 0; }
>>
>>
>> }
>
> Why is this in a subroutine at all? If you are using it like:
[stuff cut
On Sun, Jul 26, 2009 at 17:59, John W. Krahn wrote:
> Bryan Harris wrote:
snip
>> Oddly, perl won't let me do "my ($_) = shift;", so I'm stuck having to use
>> another variable.
>
> Perl 5.10 *will* let you do "my $_".
snip
Be warned that you may reveal bugs if you use make $_ lexical:
#!/usr/bin
Bryan Harris wrote:
Is it not possible to use $_ in subroutines?
Yes it is, just not the way you seem to want to use it.
For example, my temptation was to do this:
**
sub isDate {
$_ = shift;
if (m!\d{2}/\d{2}/\d{2}!) { return 1; }
else { re
Bryan Harris wrote:
... but by modifying $_ I was clobbering $_ elsewhere in the larger program!
Oddly, perl won't let me do "my ($_) = shift;", so I'm stuck having to use
another variable.
Why can't we do that? Is using $_ in subroutines discouraged??
The use of $_ in subroutines is discour
Is it not possible to use $_ in subroutines?
For example, my temptation was to do this:
**
sub isDate {
$_ = shift;
if (m!\d{2}/\d{2}/\d{2}!) { return 1; }
else { return 0; }
}
**
... but by modifying $_ I
18 matches
Mail list logo
