Perl / perl5

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

slight package name irregularity #5956

Open p5pRT opened 21 years ago

p5pRT commented 21 years ago

Migrated from rt.perl.org#17571 (status was 'open')

Searchable as RT17571$

p5pRT commented 21 years ago

From pcg@goof.com

Created by root@cerebro.laendle

The package statement accepts package names with trailing "​::" without removing them\, so

  package test​::;

  die __PACKAGE__;

outputs "test​::"\, which imho is not expected (writing "bless $ref\, test​::" for example will remove the extra "​::" at the end).

In my opinion either the package statement should rmeove the extra "​::"'s\, or it should be a syntax error.

Perl Info ``` Flags: category=core severity=low Site configuration information for perl v5.8.0: Configured by root at Sat Jul 20 01:25:22 CEST 2002. Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4, archname=i686-linux uname='linux cerebro 2.4.18-pre8-ac3 #2 smp tue feb 5 17:35:23 cet 2002 i686 unknown ' config_args='' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc-2.95.4', ccflags ='-I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-Os -funroll-loops -mcpu=pentium -march=pentium -g', cppflags='-I/opt/include -D_GNU_SOURCE -I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ccversion='', gccversion='2.95.4 20010319 (prerelease)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc-2.95.4', ldflags ='' libpth=/usr/lib /opt/lib libs=-lcrypt -ldl -lm -lc perllibs=-lcrypt -ldl -lm -lc libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared' Locally applied patches: @INC for perl v5.8.0: /root/src/sex /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 . Environment for perl v5.8.0: HOME=/root LANG (unset) LANGUAGE (unset) LC_CTYPE=de_DE@euro LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/root/s2:/root/s:/opt/qt/bin:/bin:/usr/bin:/usr/app/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/app/bin:/usr/app/sbin:/usr/X11/bin:/opt/j2sdk1.4.0_01//bin:/opt/bin:/opt/sbin:.:/root/cc/dejagnu/bin PERL5LIB=/root/src/sex PERLDB_OPTS=ornaments=0 PERL_BADLANG (unset) SHELL=/bin/bash ```
p5pRT commented 21 years ago

From @rgs

Marc Lehmann (via RT) \perlbug@​perl\.org wrote​:

The package statement accepts package names with trailing "​::" without removing them\, so

package test​::;

die __PACKAGE__;

outputs "test​::"\, which imho is not expected (writing "bless $ref\, test​::" for example will remove the extra "​::" at the end).

In my opinion either the package statement should rmeove the extra "​::"'s\, or it should be a syntax error.

I prefer the first suggestion.

Consider also :

$ perl -le 'print bless{}\,"foo​::"' foo​::=HASH(0x810ba34) $ perl -le 'print bless{}\,foo​::' foo=HASH(0x810ba34)

I think that both should return the same result.

p5pRT commented 21 years ago

From schuller@lunatech.com

On Wed\, Sep 25\, 2002 at 12​:59​:38PM +0200\, Rafael Garcia-Suarez wrote​:

$ perl -le 'print bless{}\,"foo​::"' foo​::=HASH(0x810ba34) $ perl -le 'print bless{}\,foo​::' foo=HASH(0x810ba34)

I think that both should return the same result.

It's always been possible to bless into an arbitrary string​:

$ perl -le 'print bless{}\,"\<>​:&%$#@​"' \<>​:&%@​=HASH(0x813796c)

Although I personally would have no problems if it were changed to check for valid (potential) package names.

-- Bart.

p5pRT commented 21 years ago

From @rgs

Bart Schuller \schuller@&#8203;lunatech\.com wrote​:

On Wed\, Sep 25\, 2002 at 12​:59​:38PM +0200\, Rafael Garcia-Suarez wrote​:

$ perl -le 'print bless{}\,"foo​::"' foo​::=HASH(0x810ba34) $ perl -le 'print bless{}\,foo​::' foo=HASH(0x810ba34)

I think that both should return the same result.

It's always been possible to bless into an arbitrary string​:

$ perl -le 'print bless{}\,"\<>​:&%$#@​"' \<>​:&%@​=HASH(0x813796c)

Although I personally would have no problems if it were changed to check for valid (potential) package names.

It's kind of a valid package name :

#!perl *{'\<>​:&%@​​::foo'}=sub { print "hello\n" }; $x = bless {}\, '\<>​:&%@​'; $x->foo(); # this prints hello __END__

The question is : should perl remove trailing colons from the 2nd string argument to bless ? I think it should. Currently the following :

sub foo { print "hello\n" } $x = bless {}\, 'main​::'; $x->foo();

fails with Can't locate object method "foo" via package "main​::" at x line 3.

p5pRT commented 21 years ago

From pcg@goof.com

On Wed\, Sep 25\, 2002 at 11​:57​:46AM -0000\, Bart Schuller \perlbug@&#8203;perl\.org wrote​:

On Wed\, Sep 25\, 2002 at 12​:59​:38PM +0200\, Rafael Garcia-Suarez wrote​:

$ perl -le 'print bless{}\,"foo​::"' foo​::=HASH(0x810ba34) $ perl -le 'print bless{}\,foo​::' foo=HASH(0x810ba34)

I think that both should return the same result.

It's always been possible to bless into an arbitrary string​:

I know\, still I think there shouldn't be different parsing rules for unquoted package names\, this is just (a little) confusing.

$ perl -le 'print bless{}\,"\<>​:&%$#@​"' \<>​:&%@​=HASH(0x813796c)

I wasn't talking about blessing or valid package names\, but about unquoted package names​:

  package xyz​::;

  bless {}\, xyz​::;

bless into different packages. while​:

  package "\<>​:&%$#@​";   package \<>​:&%$#@​;

are simply syntax errors.

This is more like​: "x-x" is a valid string\, but x-x is not.

Although I personally would have no problems if it were changed to check for valid (potential) package names.

"\<>​:&%$#@​" should IMHO be a valid package name - just not unquoted.

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

p5pRT commented 21 years ago

From mjtg@cam.ac.uk

Marc Lehmann wrote

The package statement accepts package names with trailing "​::" without removing them\, so

package test​::;

die __PACKAGE__;

outputs "test​::"\, which imho is not expected

It's entirely to be expected. Null fields are entirely legitimate in variable names\, and therefore in package names. Consider for example $​::x (which is the same as $main​::x) or $Class​::\, which is the symbol table for Class.

                                         \(writing "bless $ref\, test&#8203;::"

for example will remove the extra "​::" at the end).

That's rather misleading. Watch​:

  DB\<1> x bless []\, 'test​:' 0 test​:=ARRAY(0x202504)   empty array   DB\<2> x bless []\,'test​::' 0 test​::=ARRAY(0x1de714)   empty array   DB\<3> x bless []\,test​:: 0 test=ARRAY(0x1de7a4)   empty array   DB\<4>

It's not the bless() that's removing the '​::' (and it would be totally wrong if bless() did). Rather it's some odddity with bareword processing​:

  DB\<1> x test​:: 0 'test'   DB\<2>

[ Incidentally\, there seems to be something odd in the debugger here.   Why doesn't this complain?

  DB\<2> x use strict;temp​:: 0 'temp'   DB\<3> ]

Bart Schuller \schuller@&#8203;lunatech\.com wrote

It's always been possible to bless into an arbitrary string​:

$ perl -le 'print bless{}\,"\<>​:&%$#@​"' \<>​:&%@​=HASH(0x813796c)

Although I personally would have no problems if it were changed to check for valid (potential) package names.

That would break all sorts of things. For better or worse\, variable names\, and therefore package names\, are arbitrary strings. Though in general you can only access them with symbolic references.

And bless *does* check if you give it a classname argument rather than a string​:

perl -we 'use strict; print bless []\, test​::' Bareword "test​::" refers to nonexistent package at -e line 1. temp=ARRAY(0xf196c)

Mike Guy

p5pRT commented 21 years ago

From pcg@goof.com

On Wed\, Sep 25\, 2002 at 12​:11​:18PM -0000\, Rafael Garcia-Suarez \perlbug@&#8203;perl\.org wrote​:

The question is : should perl remove trailing colons from the 2nd string argument to bless ? I think it should. Currently the following :

Is it? I didn't expect such a simple almost-non-problem to spark not only so much response but also so much different opinions ;)

Ok\, I think we agree on that the current situation isn't right.

sub foo { print "hello\n" } $x = bless {}\, 'main​::';

:​: is just a way to quite (at least I read this out of the docs)\, so hello​:: is just the string "hello".

On the perl level\, "​::" in package names are not much of a divisor\, I could name my packages equally well like IO_Socket_INET etc.\, and apart from some minor differences this would be consistent (perl doesn't allow relative "namespaces" or package/namespace imports/aliase\, like e.g. modula-2 or java does)

So I'd like to argue that "​::" is an almost normal psrt of a package name. The only exception is that "barewords" (or mor specifically package names) with "​::" at the end get properly quoted.

So my only problem is that

  package packagename;

*looks* like expecting a bare package name (an expression isn't allowed\, afaics)\, but actually uses it's own set of parsing rules\, leaving trailing "​::" intact.

So\, my line of thought is​: ok\, "package" doesn't follow normal lexing rules for strings\, it expects a package name. package names can be quoted using trailing "​::". So package should accept this and strip the "​::".

However\, when one uses strings (bless {}\, "foo​::") no such quoting occurs. Different level\, namely\, bless expects a package name as a string\, always. No special :​: removal.

--   -----==- |   ----==-- _ |   ---==---(_)__ __ ____ __ Marc Lehmann +--   --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|   -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+   The choice of a GNU generation |   |

p5pRT commented 12 years ago

From @Hugmeir

On Wed Sep 25 11​:56​:49 2002\, pcg@​goof.com wrote​:

On Wed\, Sep 25\, 2002 at 12​:11​:18PM -0000\, Rafael Garcia-Suarez \perlbug@&#8203;perl\.org wrote​:

The question is : should perl remove trailing colons from the 2nd string argument to bless ? I think it should. Currently the following :

Is it? I didn't expect such a simple almost-non-problem to spark not only so much response but also so much different opinions ;)

Ok\, I think we agree on that the current situation isn't right.

sub foo { print "hello\n" } $x = bless {}\, 'main​::';

:​: is just a way to quite (at least I read this out of the docs)\, so hello​:: is just the string "hello".

On the perl level\, "​::" in package names are not much of a divisor\, I could name my packages equally well like IO_Socket_INET etc.\, and apart from some minor differences this would be consistent (perl doesn't allow relative "namespaces" or package/namespace imports/aliase\, like e.g. modula-2 or java does)

So I'd like to argue that "​::" is an almost normal psrt of a package name. The only exception is that "barewords" (or mor specifically package names) with "​::" at the end get properly quoted.

So my only problem is that

package packagename;

*looks* like expecting a bare package name (an expression isn't allowed\, afaics)\, but actually uses it's own set of parsing rules\, leaving trailing "​::" intact.

So\, my line of thought is​: ok\, "package" doesn't follow normal lexing rules for strings\, it expects a package name. package names can be quoted using trailing "​::". So package should accept this and strip the "​::".

However\, when one uses strings (bless {}\, "foo​::") no such quoting occurs. Different level\, namely\, bless expects a package name as a string\, always. No special :​: removal.

This is still present in blead. I think it should either be rejected\, or marked as WontFix; Any sort of fix now would be backwards-incompatible\, and I can't see the gain.

What would be nice (maybe worth filing a second ticket?) is getting a note in the docs that barewords with trailing :​:'s get trimmed​:

perl -MDevel​::Peek -wE '$x = \etc​::; Dump $x'

p5pRT commented 12 years ago

From @cpansprout

On Sat Apr 28 22​:48​:05 2012\, Hugmeir wrote​:

This is still present in blead. I think it should either be rejected\, or marked as WontFix; Any sort of fix now would be backwards-incompatible\, and I can't see the gain.

It does feel like a bug to me though\, that ‘package foo​::’ does not remove :​:\, while foo​:: anywhere else does lose its colons.

A quick CPAN grep for package.*​::\s*; brings up nothing.

What would be nice (maybe worth filing a second ticket?) is getting a note in the docs that barewords with trailing :​:'s get trimmed​:

perl -MDevel​::Peek -wE '$x = \etc​::; Dump $x'

I thought that was documented. Or maybe that was in the Camel.

--

Father Chrysostomos

p5pRT commented 12 years ago

From schmorp@schmorp.de

On Sun\, Apr 29\, 2012 at 12​:27​:01AM -0700\, Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org wrote​:

It does feel like a bug to me though\, that ‘package foo​::’ does not remove :​:\, while foo​:: anywhere else does lose its colons.

"package" is purely syntax\, not a function that expects a string. i would expect it would remove the :​: if it expected an expression

  package "my​::" . $pkgname;

But use cases for that are probably nonexistant (because it would be limited to compiletime).

As it stands\, word​:: is just quoting syntax (and yes\, surprisingly\, apparently undocumented outside perl5004delta and perl5005delta\, even though I think it is older - I believe I picked it up after it was discusssed on p5p). Overloading package​:: for package names would introduce yet another meaning\, and yet more special magic that people (and parsers) would have to understand. It wouldn't make anything more generic.

In fact\, it would have potential to confuse newcomers\, as the :​: really just quotes\, and it not part of the packagename.

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\