Re: base pragma (was: Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning)
On Wed, Jul 20, 2005 at 11:33:01PM -0400, Randy W. Sims wrote: > >"use base" sucks. It uses horrible heuristics to do its thing and gets > >things wrong disturbingly often. IMO its much preferable to avoid it. > >As an example play around with it with multiple packages in a single > >file, likewise play around with evaling packages into existance at run > >time, and watch use base act like its been smoking crack. What do you expect it to do in these cases? "use base" happens at compile time. In the case of the eval your class comes into existence at run time. In the multi package one I assume you're thinking of this: package Foo; use base 'Bar'; package Bar; $bar = 42; Where, similar problem, "use base 'Bar'" happens at compile time so Bar does not yet exist. The only solution I can think of is to remove the checks that the base class exists. Or if there was some way for "base" to defer its checks until after its caller has finished compiling, but I don't think that's possible. > What would break if base.pm checked %:: to see if the package is defined > /after/ it fails the C ? That would seem to solve > a large class of problems. It does do that. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in <[EMAIL PROTECTED]>
base pragma (was: Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning)
demerphq wrote: On 7/14/05, Johan Vromans <[EMAIL PROTECTED]> wrote: Rick Delaney <[EMAIL PROTECTED]> writes: use strict; package Foo::Bar; our @ISA = qw(Foo); package Foo::Baz; our @ISA = qw(Foo); This is where we have "use base" for. "use base" sucks. It uses horrible heuristics to do its thing and gets things wrong disturbingly often. IMO its much preferable to avoid it. As an example play around with it with multiple packages in a single file, likewise play around with evaling packages into existance at run time, and watch use base act like its been smoking crack. What would break if base.pm checked %:: to see if the package is defined /after/ it fails the C ? That would seem to solve a large class of problems. Randy.
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On 7/14/05, Johan Vromans <[EMAIL PROTECTED]> wrote: > Rick Delaney <[EMAIL PROTECTED]> writes: > > > use strict; > > package Foo::Bar; > > our @ISA = qw(Foo); > > > > package Foo::Baz; > > our @ISA = qw(Foo); > > This is where we have "use base" for. "use base" sucks. It uses horrible heuristics to do its thing and gets things wrong disturbingly often. IMO its much preferable to avoid it. As an example play around with it with multiple packages in a single file, likewise play around with evaling packages into existance at run time, and watch use base act like its been smoking crack. -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On Tue, Jul 19, 2005 at 12:17:43PM +0200, Rafael Garcia-Suarez wrote: > I think the "our variable redeclared" warning can be extended to the case > > our $x; our $x; > > but specifically not to the case > > our $x; package X; our $x; > > since in this latest case the 2nd $x is bound to $X::x and not > $main::x. Agreed ? Yep. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- "Lords and Ladies" by Terry Prachett
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On Tue, Jul 19, 2005 at 12:17:43PM +0200, Rafael Garcia-Suarez wrote: > > I think the "our variable redeclared" warning can be extended to the case > > our $x; our $x; > > but specifically not to the case > > our $x; package X; our $x; > > since in this latest case the 2nd $x is bound to $X::x and not > $main::x. Agreed ? Agreed. Thanks, -- Rick Delaney [EMAIL PROTECTED]
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On 7/13/05, Rick Delaney <[EMAIL PROTECTED]> wrote: > I agree too. The following patch will make the first case warn too. > Note that it also changes this current behaviour: > > % perl -wle 'our $p; package X; our $p;' > % perl -wle 'our $p; package X; my $p;' > "my" variable $p masks earlier declaration in same scope at -e line 1. I've applied a slightly modified version of your patch to bleadperl, to match the semantics defined earlier : Change 25179 on 2005/07/19 by [EMAIL PROTECTED] Overhaul the semantics of the warning ""%s" variable %s masks earlier declaration", based on a patch by Rick Delaney. Now we have : my $x; my $x; # warns my $x; our $x; # warns our $x; my $x; # warns our $x; our $x; # silent http://public.activestate.com/cgi-bin/perlbrowse?patch=25179 The presence of a package declaration between the two lexical variable delacarations doesn't change the warning case. I think the "our variable redeclared" warning can be extended to the case our $x; our $x; but specifically not to the case our $x; package X; our $x; since in this latest case the 2nd $x is bound to $X::x and not $main::x. Agreed ?
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On Thu, Jul 14, 2005 at 09:21:50AM -0700, Randal L. Schwartz wrote: > > "Rick" == Rick Delaney <[EMAIL PROTECTED]> writes: > Rick> Whatever, it was just an example. Can we get this bug resolved, > Rick> please? > > By "resolved", you mean "my $x; our $x;" needs masking warning, not > that the semantics of "our" are changed, correct? Absolutely. I think Schwern had the good sense to change the subject for the discussion of crazy ideas. ;-) -- Rick Delaney [EMAIL PROTECTED]
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
> "Rick" == Rick Delaney <[EMAIL PROTECTED]> writes: Rick> On Thu, Jul 14, 2005 at 02:05:26PM +0200, Johan Vromans wrote: >> >> This is where we have "use base" for. Rick> Whatever, it was just an example. Can we get this bug resolved, Rick> please? By "resolved", you mean "my $x; our $x;" needs masking warning, not that the semantics of "our" are changed, correct? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On Thu, Jul 14, 2005 at 02:05:26PM +0200, Johan Vromans wrote: > > This is where we have "use base" for. Whatever, it was just an example. Can we get this bug resolved, please? -- Rick Delaney [EMAIL PROTECTED]
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
Rick Delaney <[EMAIL PROTECTED]> writes: > use strict; > package Foo::Bar; > our @ISA = qw(Foo); > > package Foo::Baz; > our @ISA = qw(Foo); This is where we have "use base" for. -- Johan
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On Wed, Jul 13, 2005 at 02:01:40PM -0700, Michael G Schwern wrote: > On Wed, Jul 13, 2005 at 02:15:49AM -0400, Rick Delaney wrote: > > I agree too. The following patch will make the first case warn too. > > Note that it also changes this current behaviour: > > > > % perl -wle 'our $p; package X; our $p;' > > % perl -wle 'our $p; package X; my $p;' > > "my" variable $p masks earlier declaration in same scope at -e line 1. > > > > so that the second case doesn't warn. I can't see any reason for the > > second case to warn if the first doesn't. > > I can. > > $ perl -wle 'our $p = 42; package X; print $p;' > 42 > $ perl -wle 'our $p = 42; package X; our $p = 23; print $p;' > 23 > > That's clearly masking. "our" is lexical even crossing package boundries > (something I never realized). Declaring the same lexical variable in the > same lexical scope, whether by my or our, is masking. There is no question that it's masking but the above case was specifically coded to not produce a warning before I ever looked at the code. All I did was make it consistent, IMO. Presumably a warning is undesirable for code like use strict; package Foo::Bar; our @ISA = qw(Foo); package Foo::Baz; our @ISA = qw(Foo); where it would just be a nuisance. And as you point out, the cross-package scope can be a bit surprising. If anything I think the use of an our() variable outside its package is more deserving of a warning. package Foo::Bar; our @ISA = qw(Bar); package Foo::Baz; @ISA = qw(Baz); # we just trashed @Foo::Bar::ISA! But then, that would just annoy someone else who's using our() as described in perlfunc (which specifically describes when warnings are supposed to be produced). -- Rick Delaney [EMAIL PROTECTED]
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On Wed, Jul 13, 2005 at 02:15:49AM -0400, Rick Delaney wrote: > I agree too. The following patch will make the first case warn too. > Note that it also changes this current behaviour: > > % perl -wle 'our $p; package X; our $p;' > % perl -wle 'our $p; package X; my $p;' > "my" variable $p masks earlier declaration in same scope at -e line 1. > > so that the second case doesn't warn. I can't see any reason for the > second case to warn if the first doesn't. I can. $ perl -wle 'our $p = 42; package X; print $p;' 42 $ perl -wle 'our $p = 42; package X; our $p = 23; print $p;' 23 That's clearly masking. "our" is lexical even crossing package boundries (something I never realized). Declaring the same lexical variable in the same lexical scope, whether by my or our, is masking. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in <[EMAIL PROTECTED]>
[PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On Tue, Jul 12, 2005 at 08:29:58PM -0700, Michael G Schwern via RT wrote:
>
> This is still an issue in 5.9.x. I'd agree, there should be a warning
> particularly because all other combinations issue a warning:
>
> $ bleadperl -lwe 'my $x = 42; our $x = 23; print $x'
> 23
> $ bleadperl -lwe 'my $x = 42; my $x = 23; print $x'
> "my" variable $x masks earlier declaration in same scope at -e line 1.
> 23
> $ bleadperl -lwe 'our $x = 42; my $x = 23; print $x'
> "my" variable $x masks earlier declaration in same scope at -e line 1.
> 23
> $ bleadperl -lwe 'our $x = 42; our $x = 23; print $x'
> "our" variable $x masks earlier declaration in same scope at -e line 1.
> 23
I agree too. The following patch will make the first case warn too.
Note that it also changes this current behaviour:
% perl -wle 'our $p; package X; our $p;'
% perl -wle 'our $p; package X; my $p;'
"my" variable $p masks earlier declaration in same scope at -e line 1.
so that the second case doesn't warn. I can't see any reason for the
second case to warn if the first doesn't.
--
Rick Delaney
[EMAIL PROTECTED]
diff -ruN perl-current/pad.c perl-current-dev/pad.c
--- perl-current/pad.c 2005-07-12 20:49:00.0 -0400
+++ perl-current-dev/pad.c 2005-07-13 01:44:01.477332772 -0400
@@ -515,8 +515,7 @@
&& sv != &PL_sv_undef
&& !SvFAKE(sv)
&& (SvIVX(sv) == PAD_MAX || SvIVX(sv) == 0)
- && (!is_our
- || ((SvFLAGS(sv) & SVpad_OUR) && GvSTASH(sv) == ourstash))
+ && (!(SvFLAGS(sv) & SVpad_OUR) || GvSTASH(sv) == ourstash)
&& strEQ(name, SvPVX_const(sv)))
{
Perl_warner(aTHX_ packWARN(WARN_MISC),
diff -ruN perl-current/t/lib/warnings/pad perl-current-dev/t/lib/warnings/pad
--- perl-current/t/lib/warnings/pad 2003-11-14 18:55:28.0 -0500
+++ perl-current-dev/t/lib/warnings/pad 2005-07-13 01:49:09.614260624 -0400
@@ -33,18 +33,27 @@
my $x ;
my $x ;
my $y = my $y ;
+my $p;
+package X;
+my $p;
+package main;
no warnings 'misc' ;
my $x ;
my $y ;
EXPECT
"my" variable $x masks earlier declaration in same scope at - line 4.
"my" variable $y masks earlier declaration in same statement at - line 5.
+"my" variable $p masks earlier declaration in same scope at - line 8.
# pad.c
use warnings 'misc' ;
our $x ;
our $x ;
our $y = our $y ;
+our $p;
+package X;
+our $p;
+package main;
no warnings 'misc' ;
our $x ;
our $y ;
@@ -57,6 +66,10 @@
our $x ;
my $x ;
our $y = my $y ;
+our $p;
+package X;
+my $p;
+package main;
no warnings 'misc' ;
our $z ;
my $z ;
@@ -66,18 +79,22 @@
"my" variable $y masks earlier declaration in same statement at - line 5.
# pad.c
-# TODO not implemented yet
use warnings 'misc' ;
my $x ;
our $x ;
my $y = our $y ;
+my $p;
+package X;
+our $p;
+package main;
no warnings 'misc' ;
my $z ;
our $z ;
my $t = our $t ;
EXPECT
-"our" variable $x masks earlier declaration in same scope at - line 5.
-"our" variable $y masks earlier declaration in same statement at - line 6.
+"our" variable $x masks earlier declaration in same scope at - line 4.
+"our" variable $y masks earlier declaration in same statement at - line 5.
+"our" variable $p masks earlier declaration in same scope at - line 8.
# pad.c
use warnings 'closure' ;
@@ -219,6 +236,13 @@
use warnings 'misc' ;
+my $x;
+{
+my $x;
+}
+EXPECT
+
+use warnings 'misc' ;
our $x;
{
our $x;
@@ -227,6 +251,20 @@
"our" variable $x redeclared at - line 4.
(Did you mean "local" instead of "our"?)
+use warnings 'misc' ;
+our $x;
+{
+my $x;
+}
+EXPECT
+
+use warnings 'misc' ;
+my $x;
+{
+our $x;
+}
+EXPECT
+
# an our var being introduced should suppress errors about global syms
use strict;
use warnings;
