slight package name irregularity #5956

p5pRT · 2002-09-25T01:32:37Z

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

Searchable as RT17571$

p5pRT · 2002-09-25T01:32:37Z

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 · 2002-09-25T11:02:32Z

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 · 2002-09-25T11:57:44Z

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 · 2002-09-25T12:11:17Z

From @rgs

Bart Schuller <schuller@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 · 2002-09-25T16:09:04Z

From pcg@goof.com

On Wed, Sep 25, 2002 at 11:57:46AM -0000, Bart Schuller <perlbug@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 · 2002-09-25T16:56:56Z

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@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 · 2002-09-25T18:56:49Z

From pcg@goof.com

On Wed, Sep 25, 2002 at 12:11:18PM -0000, Rafael Garcia-Suarez <perlbug@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 · 2012-04-29T05:48:05Z

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@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 · 2012-04-29T07:27:00Z

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 · 2012-04-29T09:49:33Z

From schmorp@schmorp.de

On Sun, Apr 29, 2012 at 12:27:01AM -0700, Father Chrysostomos via RT <perlbug-followup@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
-=====/_/_//_/\_,_/ /_/\_\

p5pRT added Severity Low distro-Linux type-core labels Oct 18, 2019

xenu removed the affects-5.8 label Nov 19, 2021

xenu removed the Severity Low label Dec 29, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

slight package name irregularity #5956

slight package name irregularity #5956

p5pRT commented Sep 25, 2002

p5pRT commented Sep 25, 2002

p5pRT commented Sep 25, 2002

p5pRT commented Sep 25, 2002

p5pRT commented Sep 25, 2002

p5pRT commented Sep 25, 2002

p5pRT commented Sep 25, 2002

p5pRT commented Sep 25, 2002

p5pRT commented Apr 29, 2012

p5pRT commented Apr 29, 2012

p5pRT commented Apr 29, 2012

slight package name irregularity #5956

slight package name irregularity #5956

Comments

p5pRT commented Sep 25, 2002

p5pRT commented Sep 25, 2002

From pcg@goof.com

Created by root@cerebro.laendle

p5pRT commented Sep 25, 2002

From @rgs

p5pRT commented Sep 25, 2002

From schuller@lunatech.com

p5pRT commented Sep 25, 2002

From @rgs

p5pRT commented Sep 25, 2002

From pcg@goof.com

p5pRT commented Sep 25, 2002

From mjtg@cam.ac.uk

p5pRT commented Sep 25, 2002

From pcg@goof.com

p5pRT commented Apr 29, 2012

From @Hugmeir

p5pRT commented Apr 29, 2012

From @cpansprout

p5pRT commented Apr 29, 2012

From schmorp@schmorp.de