develooper Front page | perl.perl5.porters | Postings from September 2011

Package:: still ambiguous

Thread Next
From:
Zefram
Date:
September 13, 2011 07:22
Subject:
Package:: still ambiguous
Message ID:
20110913142151.GI18211@lake.fysh.org
We have a moderately well-known ambiguity between Foo::Bar being
a bareword package name and being a call to a subroutine.  Simple
illustration, under Devel::REPL:

$ use feature "say";
$ sub Foo::Bar::say { say "Foo::Bar::say(@_)" }
$ Foo::Bar->say(123);
Foo::Bar::say(Foo::Bar 123)
1$
$ sub Wibble::say { say "Wibble::say(@_)" }
$ sub Foo::Bar { bless({}, "Wibble") }
$ Foo::Bar->say(123);
Wibble::say(Wibble=HASH(0x965d8f4) 123)
1$

The fashionable way to disambiguate this is to add a trailing :: to
the bareword:

$ Foo::Bar::->say(123);
Foo::Bar::say(Foo::Bar 123)
1$

So 'Foo::Bar' prefers the subroutine interpretation, but 'Foo::Bar::'
is always the package name string.  However, there's also a third thing
that 'Foo::Bar' can mean:

$ open(\*Foo::Bar, ">&STDOUT");
1$
$ Foo::Bar->say(123);
Wibble::say(Wibble=HASH(0x9664bd0) 123)
1$
$ Foo::Bar::->say(123);
123
1$
$ 

'Foo::Bar' still prefers to be a sub call, but 'Foo::Bar::' is now
referring to the filehandle in preference to the package.  And that
can't be fixed by using a more obvious string syntax:

$ "Foo::Bar"->say(123);
123
1$ 

'Foo::Bar::' is still evaluating as a string, just like '"Foo::Bar"'.
The ambiguity here arises at method dispatch time, where the string
invocant is preferentially interpreted as referring to the filehandle.

It looks as if we currently have *no* unambiguous way to call class
methods.  Some people have been calling for the option to refer
to a package by its stash in Perl space, particularly to allow for
anonymous classes.  I think this issue provides another good reason to
move towards that sort of system.  As I pointed out yesterday on IRC,
there's inevitable pain if we break the current tacit guarantee that every
class has an absolute name that can be used to look it up.  I think I
didn't make clear, though, that I do think the gain is worth this effort.

I'm dubious about using stashes themselves, as they currently exist,
as the core class metaobject.  I think the visible metaobject should
be visibly of a different type from hashes.  That's not a major hassle:
stashes are already somewhat more magical than ordinary hashes.

-zefram

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About