f



"my" and "our"

Hi,

while testing a program, I erroneously declared the same variable twice
within a block, the first time with "my", the second time with "our":

{
 my $fz = 'VTX_Link';

.... ( around 200 lines of code, all in the same block)

 our $fz = 'VTX_Linkset';
 ...
}

So the initial contents of the $fz declared with "my" is lost, because
"our" creates a lexical alias for the global $fz, thus overwriting the
previous "my" declaration.

It was my error, no question. But I wonder why Perl doesn't mention
this - even with "use strict" and "use warnings" set. Unlike as in the
reverse case - declaring the variable first with "our" and then with "my"
results in the message

"my" variable $fz masks earlier declaration in same scope at ...

And declaring the variable twice with "our" shows a similar message
("our" variable $fz masks earlier declaration...). Only in the above case,
nothing is shown.

Is this expected behaviour (I tried 5.6.1, 5.8.6 and 5.8.7)?

Kind greetings,

Ferry
--

Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at


0
bol (112)
5/18/2006 10:46:44 AM
comp.lang.perl.misc 33233 articles. 1 followers. brian (1246) is leader. Post Follow

5 Replies
786 Views

Similar Articles

[PageSpeed] 55

Quoth "Ferry Bolhar" <bol@adv.magwien.gv.at>:
> Hi,
> 
> while testing a program, I erroneously declared the same variable twice
> within a block, the first time with "my", the second time with "our":
> 
> {
>  my $fz = 'VTX_Link';
> 
> ... ( around 200 lines of code, all in the same block)
> 
>  our $fz = 'VTX_Linkset';
>  ...
> }
> 
> So the initial contents of the $fz declared with "my" is lost, because
> "our" creates a lexical alias for the global $fz, thus overwriting the
> previous "my" declaration.
> 
> It was my error, no question. But I wonder why Perl doesn't mention
> this - even with "use strict" and "use warnings" set. Unlike as in the
> reverse case - declaring the variable first with "our" and then with "my"
> results in the message
> 
> "my" variable $fz masks earlier declaration in same scope at ...
> 
> And declaring the variable twice with "our" shows a similar message
> ("our" variable $fz masks earlier declaration...). Only in the above case,
> nothing is shown.
> 
> Is this expected behaviour (I tried 5.6.1, 5.8.6 and 5.8.7)?

Hmm... I would call it a bug...

The relevant piece of code is (in 5.8.7) at pad.c:516:

    [more conditions]
    
    && (!is_our
        ^^ new variable is a 'my'
    
        || ((SvFLAGS(sv) & SVpad_OUR) && GvSTASH(sv) == ourstash))
        ^^ or     old var is 'our'    and is an alias to the same global
        
    && strEQ(name, SvPVX(sv)))
    ^^ and the names are the same

I guess it's there so you can have

    package foo;
    our $x;
    package bar;
    our $x;

without a warning; however, I would have said your case should give a
warning. The change would be simple: I should talk to p5p, there may be
a reason.

Ben

-- 
   If you put all the prophets,   |   You'd have so much more reason
   Mystics and saints             |   Than ever was born
   In one room together,          |   Out of all of the conflicts of time.
benmorrow@tiscali.co.uk                             The Levellers, 'Believers'
0
Ben
5/18/2006 3:18:02 PM
Ferry Bolhar wrote:
> {
>  my $fz = 'VTX_Link';
>
> ... ( around 200 lines of code, all in the same block)
>
>  our $fz = 'VTX_Linkset';
>  ...
> }

> It was my error, no question. But I wonder why Perl doesn't mention
> this - even with "use strict" and "use warnings" set. Unlike as in the
> reverse case - declaring the variable first with "our" and then with "my"
> results in the message
>
> "my" variable $fz masks earlier declaration in same scope at ...

I'd definitely call this a bug in perl. But that said we can't rely too
much on "masks earlier declaration" wanings as they'll never spot...

 {
  my $fz = 'VTX_Link';
  ... ( around 200 lines of code, all in the same block)
 { 
    our $fz = 'VTX_Linkset';
    ...
  }
}

0
Brian
5/18/2006 5:05:09 PM
"Ferry Bolhar" <bol@adv.magwien.gv.at> wrote in message 
news:1147949205.299835@proxy.dienste.wien.at...
> Hi,
>
> while testing a program, I erroneously declared the same variable twice
> within a block, the first time with "my", the second time with "our":
>
> {
> my $fz = 'VTX_Link';
>
> ... ( around 200 lines of code, all in the same block)
>
> our $fz = 'VTX_Linkset';
> ...
> }
>
> So the initial contents of the $fz declared with "my" is lost, because
> "our" creates a lexical alias for the global $fz, thus overwriting the
> previous "my" declaration.
>
> It was my error, no question. But I wonder why Perl doesn't mention
> this - even with "use strict" and "use warnings" set. Unlike as in the
> reverse case - declaring the variable first with "our" and then with "my"
> results in the message
>
> "my" variable $fz masks earlier declaration in same scope at ...
>
> And declaring the variable twice with "our" shows a similar message
> ("our" variable $fz masks earlier declaration...). Only in the above case,
> nothing is shown.
>
> Is this expected behaviour (I tried 5.6.1, 5.8.6 and 5.8.7)?
>
> Kind greetings,
>
> Ferry
> --
>
> Ing. Ferry Bolhar
> Municipality of Vienna, Department 14
> A-1010 Vienna / AUSTRIA
> E-mail: bol@adv.magwien.gv.at
>
>

The PBP recommendation to use longer descriptive names for variables whose 
scope more than a few lines (I'm paraphrasing here) would help you avoid 
such problems. The names should include something that indicates what is 
distinctive between the two. You should also reconsider whether you really 
need to use a package variable...

Dave



0
Dave
5/19/2006 7:33:58 AM
Dave:

> The PBP recommendation to use longer descriptive names for variables whose
> scope more than a few lines (I'm paraphrasing here) would help you avoid
> such problems.

May be, may not be. I used "fz" as abbreviation for "format zone"; that's
what
$fz is used for. And if I had spelled out the name fully, I also would spell
it out
a second time, so I'm not sure whether this recommandation actually had
solved
this problem.

The problem here is that data is changed unexpectedly - the original value
of the
lexical is overwritten by the global $fz value. Even one could access the
lexical
$fz (perhaps by a pseudo package "My::" - how about this?), its originally
assigned value is lost. And this should be mentioned by Perl absolutely -
IMHO
even without "use warnings".

Greetings, Ferry

-- 
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at


0
Ferry
5/19/2006 11:47:42 AM
"Ferry Bolhar" <bol@adv.magwien.gv.at> wrote in message 
news:1148039262.662241@proxy.dienste.wien.at...
> Dave:
>
>> The PBP recommendation to use longer descriptive names for variables 
>> whose
>> scope more than a few lines (I'm paraphrasing here) would help you avoid
>> such problems.
>
> May be, may not be. I used "fz" as abbreviation for "format zone"; that's
> what
> $fz is used for. And if I had spelled out the name fully, I also would 
> spell
> it out
> a second time, so I'm not sure whether this recommandation actually had
> solved
> this problem.
>
> The problem here is that data is changed unexpectedly - the original value
> of the
> lexical is overwritten by the global $fz value. Even one could access the
> lexical
> $fz (perhaps by a pseudo package "My::" - how about this?), its originally
> assigned value is lost. And this should be mentioned by Perl absolutely -
> IMHO
> even without "use warnings".
>
> Greetings, Ferry
>
> -- 
> Ing. Ferry Bolhar
> Municipality of Vienna, Department 14
> A-1010 Vienna / AUSTRIA
> E-mail: bol@adv.magwien.gv.at
>
>

I think the point is that as your two variables refer to 'format zones' that 
are different in some way their names should reflect with by the addition of 
a suitable adjective. However I agree that the masking of a lexical by a 
package variable should ideally provoke a warning and that a mechanism to 
access the hidden lexical would be handy.

As you do not include a short but complete program that illustrates the 
problem as a whole it is difficult to know whether using the 'our' 
declaration is appropriate or not to what you are trying to do.


0
Dave
5/19/2006 3:23:37 PM
Reply: