Open p5pRT opened 11 years ago
These package names are all condemned\, to be forbidden in perl 5.20 or possibly perl 5.22.
package ::X package X:: package X::::Y
...and especially:
package ::
Similarly any package names which use ' to similar effect. The removal of the package separator ' from perl is out of scope for this ticket.
-- rjbs
On 3/7/13\, Ricardo SIGNES \perlbug\-followup@​perl\.org wrote:
These package names are all condemned\, to be forbidden in perl 5.20 or possibly perl 5.22.
package ::X
Would this forbid "::X" as a package name string too? Currently "::X" is a synonym to "main::X"\, which differs from "X" in that when you call a method on the string it will check *main::X{IO} instead of *X{IO} in the current package.
Ambrus
The RT System itself - Status changed from 'new' to 'open'
On Thu\, Mar 7\, 2013 at 6:18 PM\, ZsbĂĄn Ambrus \ambrus@​math\.bme\.hu wrote:
On 3/7/13\, Ricardo SIGNES \perlbug\-followup@​perl\.org wrote:
These package names are all condemned\, to be forbidden in perl 5.20 or possibly perl 5.22.
package ::X
Would this forbid "::X" as a package name string too? Currently "::X" is a synonym to "main::X"\, which differs from "X" in that when you call a method on the string it will check *main::X{IO} instead of *X{IO} in the current package.
Ambrus
I'm wondering the same thing. Unlike foo::::bar or foo::\, ::foo actually has a documented meaning. I don't think this should be deprecated. The rest can rot though.
On Thu\, Mar 07\, 2013 at 06:36:39PM -0300\, Brian Fraser wrote:
On Thu\, Mar 7\, 2013 at 6:18 PM\, ZsbĂĄn Ambrus \ambrus@​math\.bme\.hu wrote:
On 3/7/13\, Ricardo SIGNES \perlbug\-followup@​perl\.org wrote:
These package names are all condemned\, to be forbidden in perl 5.20 or possibly perl 5.22.
package ::X
Would this forbid "::X" as a package name string too? Currently "::X" is a synonym to "main::X"\, which differs from "X" in that when you call a method on the string it will check *main::X{IO} instead of *X{IO} in the current package.
Ambrus
I'm wondering the same thing. Unlike foo::::bar or foo::\, ::foo actually has a documented meaning. I don't think this should be deprecated. The rest can rot though.
Foo:: has a documented meaning too - it's a form of quoting\, so that Foo::->new always means "Foo"->new\, and never Foo()->new (which is the default interpretation of Foo->new).
That said\, I'm fairly sure that all of these forms are only being deprecated in package statements - I don't see any reason why "package ::X" or "package X::" are reasonable things to do.
-doy
* Jesse Luehrs \doy@​tozt\.net [2013-03-07T16:42:45]
Foo:: has a documented meaning too - it's a form of quoting\, so that Foo::->new always means "Foo"->new\, and never Foo()->new (which is the default interpretation of Foo->new).
That said\, I'm fairly sure that all of these forms are only being deprecated in package statements - I don't see any reason why "package ::X" or "package X::" are reasonable things to do.
More importantly\, in package names\, even if the practical effect is largely through the "package" statement. It doesn't affect the meaning of $::x or Foo::
$x::::y is right out\, though.
-- rjbs
On Fri\, Mar 8\, 2013 at 1:28 AM\, Ricardo Signes \perl\.p5p@​rjbs\.manxome\.org wrote:
* Jesse Luehrs \doy@​tozt\.net [2013-03-07T16:42:45]
Foo:: has a documented meaning too - it's a form of quoting\, so that Foo::->new always means "Foo"->new\, and never Foo()->new (which is the default interpretation of Foo->new).
That said\, I'm fairly sure that all of these forms are only being deprecated in package statements - I don't see any reason why "package ::X" or "package X::" are reasonable things to do.
More importantly\, in package names\, even if the practical effect is largely through the "package" statement. It doesn't affect the meaning of $::x or Foo::
$x::::y is right out\, though.
-- rjbs
https://github.com/Hugmeir/utf8mess/tree/deprecate_weird_package_separators
That branch introduces four new warnings/deprecations:
* Use of empty package names is deprecated package ::; sub ::; sub foo::::bar; $foo::::bar; $foo::'bar; ::::foo;
* Use of trailing double colons in sub or package declaration is deprecated package foo::; sub foo::;
Use of leading double colons in package declarations is deprecated package ::foo;
Use of leading double colons in barewords is deprecated say STDOUT ::foo; # assuming main::foo isn't a subroutine and strict isn't enabled.
That being said\, the implementation for the 'package ...;' warnings is pretty icky\, as it replies on an implementation detail: forced_word() internally calls scan_word()\, saving the identifier in PL_tokenbuf\, so we can check that afterwards. I assume that's safe for the time being? The alternative is inlining the parts of force_word that we need in the KEY_package case\, but that seemed a needless forward-incompatible hassle for just a deprecation warning.
On Thu Mar 07 20:29:25 2013\, perl.p5p@rjbs.manxome.org wrote:
* Jesse Luehrs \doy@​tozt\.net [2013-03-07T16:42:45]
Foo:: has a documented meaning too - it's a form of quoting\, so that Foo::->new always means "Foo"->new\, and never Foo()->new (which is the default interpretation of Foo->new).
That said\, I'm fairly sure that all of these forms are only being deprecated in package statements - I don't see any reason why "package ::X" or "package X::" are reasonable things to do.
More importantly\, in package names\, even if the practical effect is largely through the "package" statement. It doesn't affect the meaning of $::x or Foo::
$x::::y is right out\, though.
But why? Is it harmful? I actually find $x::::y useful\, as âuse Foo::::Barâ vs âuse Foo::Barâ actually lets me have two separate import subs in the same module.
It may be uncommon\, but I have actual code using that.
Also\, arbitrary string are currently allowed for ${"..."}. I hope *that* doesnât change!
--
Father Chrysostomos
On Fri Mar 15 12:08:41 2013\, Hugmeir wrote:
https://github.com/Hugmeir/utf8mess/tree/deprecate_weird_package_separators
It produces strange test output from lex.t:
ok 55 ok 56 ok $test - heredoc after "" in s/// in eval ok $test - heredoc in "" in multiline s///e in eval ok 59 - null on same line as heredoc in s/// in eval ok 60 - heredoc in "" in single-line s///e in eval ok 61 - heredoc in "" in multiline s///e outside eval
Removing the \ from the \<\<\END in each test fixes that\, but I'm not sure if it then continues to test what was intended.
Tony
On Mon Jul 15 18:12:31 2013\, tonyc wrote:
On Fri Mar 15 12:08:41 2013\, Hugmeir wrote:
https://github.com/Hugmeir/utf8mess/tree/deprecate_weird_package_separators
It produces strange test output from lex.t:
ok 55 ok 56 ok $test - heredoc after "" in s/// in eval ok $test - heredoc in "" in multiline s///e in eval ok 59 - null on same line as heredoc in s/// in eval ok 60 - heredoc in "" in single-line s///e in eval ok 61 - heredoc in "" in multiline s///e outside eval
Removing the \ from the \<\<\END in each test fixes that\, but I'm not sure if it then continues to test what was intended.
I've attached the rebased patches\, but the final patch is obviously incomplete.
Tony
On Wed Jul 31 22:29:40 2013\, tonyc wrote:
I've attached the rebased patches\, but the final patch is obviously incomplete.
Brian updated his branch on github\, I've attached the new patch series.
Tony
On Sun Aug 04 18:59:28 2013\, tonyc wrote:
On Wed Jul 31 22:29:40 2013\, tonyc wrote:
I've attached the rebased patches\, but the final patch is obviously incomplete.
Brian updated his branch on github\, I've attached the new patch series.
Tony
The only questionable part to me (besides some whitespace issues)\, is this modification to S_scan_word():
@@ -9360\,6 +9396\,8 @@ S_scan_word(pTHX_ char *s\, char *dest\, STRLEN destlen\, int allow_package\, STRLEN parse_ident(&s\, &d\, e\, allow_package\, is_utf8); *d = '\0'; *slp = d - dest; + if ( allow_package && *slp && *slp >= 4 ) + deprecate_empty_packages(dest); return s; }
I know parsers (and especially perl's parser) tend to be messy\, but I'm not sure that check belongs in scan_word - changing it from "scan a word" to "scan a word and optionally warn".
Unless someone else speaks up I plan to apply it as is (with whitespace fixes.)
Tony
On Sun Aug 04 19:02:50 2013\, tonyc wrote:
On Sun Aug 04 18:59:28 2013\, tonyc wrote:
On Wed Jul 31 22:29:40 2013\, tonyc wrote:
I've attached the rebased patches\, but the final patch is obviously incomplete.
Brian updated his branch on github\, I've attached the new patch series.
Tony
The only questionable part to me (besides some whitespace issues)\, is this modification to S_scan_word():
@@ -9360\,6 +9396\,8 @@ S_scan_word(pTHX_ char *s\, char *dest\, STRLEN destlen\, int allow_package\, STRLEN parse_ident(&s\, &d\, e\, allow_package\, is_utf8); *d = '\0'; *slp = d - dest; + if ( allow_package && *slp && *slp >= 4 ) + deprecate_empty_packages(dest); return s; }
I know parsers (and especially perl's parser) tend to be messy\, but I'm not sure that check belongs in scan_word - changing it from "scan a word" to "scan a word and optionally warn".
That could be problematic if scan_word is called multiple times for the same word\, which is not implausible. Finding out whether that can happen will take some work.
Unless someone else speaks up I plan to apply it as is (with whitespace fixes.)
Are we going to apply it before we have even discussed why we are deprecating this\, i.e.\, what problem we are trying to solve?
Also\, deprecating leading :: except when a sub with that name exists doesnât make sense to me. Thatâs deprecating something except when people use it.
--
Father Chrysostomos
On Sun Aug 04 23:37:20 2013\, sprout wrote:
On Sun Aug 04 19:02:50 2013\, tonyc wrote:
Unless someone else speaks up I plan to apply it as is (with whitespace fixes.)
Are we going to apply it before we have even discussed why we are deprecating this\, i.e.\, what problem we are trying to solve?
Also\, deprecating leading :: except when a sub with that name exists doesnât make sense to me. Thatâs deprecating something except when people use it.
I'm not too worried either way about the deprecation\, but I didn't find your arguments all that convincing.
I don't have a problem with more discussion\, though I feel a bit bad for Brian over the work he's done on the patch if it doesn't go ahead.
Tony
On Mon Aug 05 17:15:10 2013\, tonyc wrote:
On Sun Aug 04 23:37:20 2013\, sprout wrote:
On Sun Aug 04 19:02:50 2013\, tonyc wrote:
Unless someone else speaks up I plan to apply it as is (with whitespace fixes.)
Are we going to apply it before we have even discussed why we are deprecating this\, i.e.\, what problem we are trying to solve?
Also\, deprecating leading :: except when a sub with that name exists doesnât make sense to me. Thatâs deprecating something except when people use it.
I'm not too worried either way about the deprecation\, but I didn't find your arguments all that convincing.
I don't have a problem with more discussion\,
I have not yet heard any arguments in favour of the deprecation\, other than âwe are going to do thisâ. I would like to know what problem is being solved here.
though I feel a bit bad for Brian over the work he's done on the patch if it doesn't go ahead.
Brian\, I hope you donât feel bad. After all\, weâve all written patches that havenât been applied. :-)
--
Father Chrysostomos
My two cents is that this deprecation will be particularly useful in clearing up some odd cases with the old ' package separator used in doublequoted strings. Those do cause bugs in practice (speaking from my experience). If deprecating the weird empty package names in general is the easiest way to do that, so be it.
There are also arguments from the correspondence between package names and .pm files in the filesystem.
Migrated from rt.perl.org#117087 (status was 'open')
Searchable as RT117087$