search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.86k stars 527 forks source link

package NAMESPACE manpage comments #12247

Closed p5pRT closed 11 years ago

p5pRT commented 11 years ago

Migrated from rt.perl.org#113974 (status was 'rejected')

Searchable as RT113974$

p5pRT commented 11 years ago

From @doy

On Fri\, Jul 06\, 2012 at 10​:43​:40PM -0700\, Linda W wrote​:

Personally\, I'd like to see 'our' create a package scoped variable that exists wherever the package is.

I very much wouldn't. The current behavior of our actually makes sense in terms of scoping\, really don't think we need to be moving backwards here.

-doy

p5pRT commented 11 years ago

From @rjbs

* demerphq \demerphq@​gmail\.com [2012-07-06T12​:16​:19]

Anyway\, I really hope Ricardo puts some thought into this\, at a deep level\, and resists the urge to base his decisions on optimizations and new features which IMO break the original model and then gets back to us with how it SHOULD be seen and dealt with\, and then we can move on from there.

I personally will not accept any argument that is based on the current broken behavior of our as I consider the behavior of the following code to be plain and simply a bug. [code]

I'm just not sure what you're suggesting.

I see that when I asked what you thought your code sample should do\, it didn't get back to the list. Oops!

"our" seems to do exactly what I'd expect given the explanation I've always had in my head​: a lexical name pointing at package storage.

I went and reviewed the original thread about 'our' here​: http​://markmail.org/thread/37ma5sf2fr75dwxt -- once again taking us to the summer of 1999!

I didn't see anything convincing me that "our" was supposed to work differently than it does now.

-- rjbs

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Personally\, I'd like to see 'our' create a package scoped variable that exists wherever the package is.

I very much wouldn't. The current behavior of our actually makes sense in terms of scoping\, really don't think we need to be moving backwards here.

I was easy to convince ... chromatic inspired the answer​:

chromatic via RT wrote​:

My feedback is "please don't break working code when a perfectly good mechanism already exists to do what you want".

Perfectly good? Why not just make "use vars qw(xxx);" (or is that C\<\< use var qw(xxx);>>?) into​:

  "vars $one\, $two;" (?C\<\<vars $one\, $two;>>?)

as a full-fledged declaration that does was this -- i.e. associates a name with a package var in any package of the same name (i.e. aliased to ${__PACKAGE__ ."​::var"} )? Seems like those who wanna discourage use vars can continue to do so as archaic\, while package vars become first class citizens and not just wanderer's across the scope of a file...

p5pRT commented 11 years ago

From @Leont

On Sat\, Jul 7\, 2012 at 12​:39 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

Perfectly good?

Your perfect maybe\,

Why not just make use vars qw(xxx) into

vars $one\, $two;

Why would we? Package vars is not something people should be using often anyway in modular Perl\, having a yet another option for handling them seems rather superfluous. Besides\, it's not like these difference matter in clean code anyway.

and have it be what our was supposed to be?

Then you can have your cake and vars can too!

Because the lexical scope reduces action at a distance to something that's predictable\, even if it's occasionally not what you want.

Leon

p5pRT commented 11 years ago

From tchrist@perl.com

Jesse Luehrs \doy@&#8203;tozt\.net wrote on Sat\, 07 Jul 2012 08​:05​:21 CDT​:

On Fri\, Jul 06\, 2012 at 10​:43​:40PM -0700\, Linda W wrote​:

Personally\, I'd like to see 'our' create a package scoped variable that exists wherever the package is.

I very much wouldn't. The current behavior of our actually makes sense in terms of scoping\, really don't think we need to be moving backwards here.

Agreed. Making "our" switch around with changes in the default package instead of changes in scope would be two steps in the wrong direction.

--tom

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Leon Timmermans via RT wrote​:

On Sat\, Jul 7\, 2012 at 12​:39 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

Perfectly good?

Your perfect maybe\,

Why not just make use vars qw(xxx) into

vars $one\, $two;

Why would we? Package vars is not something people should be using often anyway in modular Perl\, having a yet another option for handling them seems rather superfluous. Besides\, it's not like these difference matter in clean code anyway.

  Develop a large package across multiple files... call it unclean see if anyone cares.

Because the lexical scope reduces action at a distance to something that's predictable\, even if it's occasionally not what you want.

??? use package indiana; {pop context and "our $pi=3"} package math; our $pi=4*atan(1\,1); package cad;

design circular structure; using $pi';

yeah\, real predictable....

thanks indiana! ;-/

hey\, don't say it can't happen\, murphy's got at least a $20...

Leon

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Leon Timmermans via RT wrote​:

On Sat\, Jul 7\, 2012 at 12​:39 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

Perfectly good?

Your perfect maybe\,

Why not just make use vars qw(xxx) into

vars $one\, $two;

Why would we? Package vars is not something people should be using often anyway in modular Perl\, having a yet another option for handling them seems rather superfluous. Besides\, it's not like these difference matter in clean code anyway

  Actually better example... main split across 3 places due to BEGIN requirements.

beginning because it is the default where one expects program constants\,

after a 'vars' routine that runs at begin time\, so main can have some too\,

then the main code down below after everything is defined.

Clean code? in perl? yeah\, it happens\, but to get around language restrictions\, my code is hardly what I'd call 'clean'...

p5pRT commented 11 years ago

From @ikegami

On Sat\, Jul 7\, 2012 at 3​:08 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

Develop a large package across multiple files\.\.\. call it unclean see

if anyone cares.

C\ does already handles this perfectly. Anything lexically scoped wouldn't.

p5pRT commented 11 years ago

From @demerphq

On 7 July 2012 04​:08\, Ricardo Signes \perl\.p5p@&#8203;rjbs\.manxome\.org wrote​:

* demerphq \demerphq@&#8203;gmail\.com [2012-07-06T12​:16​:19]

I personally will not accept any argument that is based on the current broken behavior of our as I consider the behavior of the following code to be plain and simply a bug.

package Foo; use vars qw($FOO); $FOO="FOO";

package Bar; print $FOO;

package Baz; our $BAZ;

$BAZ= "BAZ";

package Bop;

print $BAZ;

What do you suggest that this code *should* do?

You think that $BAZ in the last instance should *not* find the same variable as the one to which "BAZ" was assigned\, or?

Yes correct. It should behave the same way it would if it were fully qualified or if it was declared with use vars.

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT commented 11 years ago

From @demerphq

On 7 July 2012 15​:50\, Ricardo Signes \perl\.p5p@&#8203;rjbs\.manxome\.org wrote​:

* demerphq \demerphq@&#8203;gmail\.com [2012-07-06T12​:16​:19]

Anyway\, I really hope Ricardo puts some thought into this\, at a deep level\, and resists the urge to base his decisions on optimizations and new features which IMO break the original model and then gets back to us with how it SHOULD be seen and dealt with\, and then we can move on from there.

I personally will not accept any argument that is based on the current broken behavior of our as I consider the behavior of the following code to be plain and simply a bug. [code]

I'm just not sure what you're suggesting.

I see that when I asked what you thought your code sample should do\, it didn't get back to the list. Oops!

"our" seems to do exactly what I'd expect given the explanation I've always had in my head​: a lexical name pointing at package storage.

My understanding of our was that it was intended as a lexically scoped equivalent to use vars.

The proposed implementation appears to have provided some subtly different behavior.

I went and reviewed the original thread about 'our' here​: http​://markmail.org/thread/37ma5sf2fr75dwxt -- once again taking us to the summer of 1999!

I didn't see anything convincing me that "our" was supposed to work differently than it does now.

At the intent level or the implementation level? I have added things to perl with a specific intent only to discover that the implementation resulted in something a little different than I had planned. People reviewing my implementation would naturally assume that what it does was what it was intended to do\, despite the fact it doesn't.

cheers\, Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT commented 11 years ago

From @demerphq

On 8 July 2012 13​:03\, demerphq \demerphq@&#8203;gmail\.com wrote​:

On 7 July 2012 15​:50\, Ricardo Signes \perl\.p5p@&#8203;rjbs\.manxome\.org wrote​:

I went and reviewed the original thread about 'our' here​: http​://markmail.org/thread/37ma5sf2fr75dwxt -- once again taking us to the summer of 1999!

I just read further and now I see that Larry intended this behavior. So I withdraw most of my comments in this thread. Sorry for the noise.

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT commented 11 years ago

From @jkeenan

On Sun Jul 08 04​:17​:50 2012\, demerphq wrote​:

On 8 July 2012 13​:03\, demerphq \demerphq@&#8203;gmail\.com wrote​:

On 7 July 2012 15​:50\, Ricardo Signes \perl\.p5p@&#8203;rjbs\.manxome\.org wrote​:

I went and reviewed the original thread about 'our' here​: http​://markmail.org/thread/37ma5sf2fr75dwxt -- once again taking us to the summer of 1999!

I just read further and now I see that Larry intended this behavior. So I withdraw most of my comments in this thread. Sorry for the noise.

Yves

This ticket generated a lot of discussion but\, AFAICT\, no usable patches.

I propose that we close the ticket and will do so in seven days unless there is a significant objection. I recommend that if someone wishes to pursue the discussion\, submit a patch in a new RT.

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

From @jkeenan

On Tue Sep 18 18​:50​:49 2012\, jkeenan wrote​:

On Sun Jul 08 04​:17​:50 2012\, demerphq wrote​:

On 8 July 2012 13​:03\, demerphq \demerphq@&#8203;gmail\.com wrote​:

On 7 July 2012 15​:50\, Ricardo Signes \perl\.p5p@&#8203;rjbs\.manxome\.org wrote​:

I went and reviewed the original thread about 'our' here​: http​://markmail.org/thread/37ma5sf2fr75dwxt -- once again taking us to the summer of 1999!

I just read further and now I see that Larry intended this behavior. So I withdraw most of my comments in this thread. Sorry for the noise.

Yves

This ticket generated a lot of discussion but\, AFAICT\, no usable patches.

I propose that we close the ticket and will do so in seven days unless there is a significant objection. I recommend that if someone wishes to pursue the discussion\, submit a patch in a new RT.

Thank you very much. Jim Keenan

No comments received in > 7 days. Closing.

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

@jkeenan - Status changed from 'open' to 'rejected'