Instead of a class name or an object reference, you can also use any expression that returns either of those on the left side of the arrow.

So the following statement is valid:

    Critter->find("Fred")->display("Height", "Weight");
[download]

    my $fred = (reverse "rettirC")->find(reverse "derF");
[download]

One reason that it is a Very Good Thing that it works this way is that it allows you to write things like subclassable factories, where the class of the thing being constructed is determined by the factory subclass.

  package Factory;

  sub makeThing {
    my ($class, @args) = @_;
    my $thingClass = $class->thingClass;
    my $thing = $thingClass->new(@args);
    $class->magicStuff($thing);
    return $thing;
  }

  sub thingClass { 'Thing' }

  sub magicStuff {
    my ($class, $thing) = @_;
    # pretend there's generic magic stuff here
  }
[download]

Now, to change the class of the thing being constructed, you simply subclass the factory class and override one method.

  package SpecialFactory;
  use base qw(Factory);

  sub thingClass { 'SpecialThing' }
[download]

Now, Factory->makeThing gives you a Thing, and SpecialFactory->makeThing gives you a SpecialThing.

or you could even

sub thingClass { ref $_[0] }
[download]

in the base class, and forget about having to create overrides.

When you get down to it, a perl namespace is just a string. It gets mapped into the symbol table by simple trickery involving string operations.

A class constructor method new() usually starts with,

sub new {
    my $class = shift;
[download]

    bless $self, $class;
}
[download]

If you look at the docs for bless, you'll see that all it needs is a string in the second argument. There is nothing to prevent you from blessing a reference into any string you like:

perl -Mstrict -we'my $vanilla = bless {}, "Im a Pudding"; print ref $v
+anilla, $/'
Im a Pudding
[download]

So you're doing the right thing. There are no reference or alias issues, and strict doesn't raise a peep.

A symbolic reference to a package is all there is so we can't disallow it. A symbolic reference to a variable is what use strict 'refs' disallows.

Now, I don't like symbolic references to packages much. I'd require (well, encourage anyway) that you mention the package once to load it and that process would give you a handle to the package that you use instead of repeating the package name all over the place.

Package names should be world-wide unique, which means they can get rather long. So I'd like to start my code more like:

use strict;
my $Heap= require Data::Heap;
my $Parser= require XML::Twig;
my $q= require Net::CGI;
my $Bank= require Finance::Banking::English::USA::CreditUnion::CA::Poi
+ntMagu;

...
[download]

If such became well supported, then you could define a "package reference" like we defined "scalar reference", "hash reference", and the rest. Then require could default to returning this new type of non-symbolic reference and you could make using a symbolic reference optionally cause an error just like other symbolic references.

This would also solve a lot of complex problems. You could have multiple versions of the same package loaded at the same time quite easily. Modules wouldn't have to break if they were installed in the wrong place (a user could pick a non-default place to install a module and give the designation for that location to require and it would find the module file and load it and things would just work without having to change the module name declared inside the module etc.).

Well, solving those things becomes easy if you disallow symbolic references to packages like Perl disallows symbolic references to lexical variables. Rather, if you make it so that require is the only way to get a reference to a package.

This actually creates a few namespaces that are quite natural. Modules get the namespace by which they are normally referred such as "Algorithm::Diff" (no change from how things work today). When a module is loaded, it gets named by the path to the file that it was loaded from (this way you can have two different versions of one module that even have the same version number and yet they both can work fine in a single instance of the Perl interpreter at the same time). require takes "Algorithm::Diff" and uses the current scheme to transform that into a path name. But when it loads the code in that file, it gets loaded into a package specific to that path string not named by some 'package' statement in the file.

And the module code only states the base module name once for documentation purposes and the user of the module also only types in this name once.

I think that would be cool. (But having require return the factory for the module, even w/o all of the other features, would still be nice.)

Foo::Bar::Baz->new()
[download]

Something else you can do is:

sub Baz () { 'Foo::Bar::Baz' }
$baz = Baz->new();
[download]

$ perl -MO=Deparse,-x7 -e'Foo::Bar->new()'
'Foo::Bar'->new;
-e syntax OK
[download]

Pay attention to the quotes: as far as Perl is concerned, class methods are always invoked on a string containing the package name. Whether that's a literal string or one stored in a variable matters naught.

Makeshifts last the longest.

It even turns out that there is no speed difference. (I expected *some* advantage to the inline string, because there'd be an extra indirection. But it's lost to the method call overhead.)

use Benchmark;

package Bar;

sub new {};

package main;

my $obj;
my $class = "Bar";  # "our" *is* slower, though.

timethese -1, {
    bareword => sub { $x = Bar->new()    },
    var      => sub { $x = $class->new() },
};

#########################################

Benchmark: running bareword, var for at least 1 CPU seconds...
  bareword:  1 wallclock secs ( 1.06 usr +  0.00 sys =  1.06 CPU) @ 59
+0160.38/s (n=625570)
       var:  1 wallclock secs ( 1.06 usr +  0.00 sys =  1.06 CPU) @ 59
+0160.38/s (n=625570)
[download]