Re: use Very::Long::Module::Name as Foo;

[tilly]

Sorry, but I prefer the existing solutions.

In terms of complexity to use, all of the proposed solutions, including yours, are about equal. In terms of conceptual difficulty for a Perl programmer to figure out how they work under the hood, yours is significantly more complicated. In terms of avoiding possible conflicts between different modules making use of the feature, I prefer either putting the package name in a variable or a constant to anything that tramples over short global namespaces that other modules don't expect you to trample over.

Also I like reserving source filtering for when it really buys a lot because I am afraid that, going forward, we will wind up with "interesting conflicts" because different source filters won't cooperate well with each other. (The heuristics which one uses to figure out what is going on don't take into account how the previous one altered Perl.) Traditional Perl modules have much lower odds of conflict.

In fact a private theory of mine holds that one of the keys to what made CPAN work is that Perl didn't used to lend itself to customization, so code that worked for you probably works without many issues in my environment, and vice versa. This makes sharing easy. Compare, say, to a significant body of C code with heavy use of pre-processor definitions.

[liz]

In terms of complexity to use, all of the proposed solutions, including yours, are about equal...

I disagree with that. I think:

use Very::Long::Module::Name as Foo;

is definitely easier to type and to the eye than:

use as qw(Very::Long::Module::Name Foo); # Package Alias approach

especially when it comes to parametrized uses. These would all work with my source filter:

use Very::Long::Module::Name as Foo qw(foo bar baz); # import foo, bar
+ baz
use Very::Long::Module::Name as Foo (); # don't import

Package::Alias (and Abigail's approach) does not support this.

...conceptual difficulty for a Perl programmer to figure out how they work under the hood...

I also disagree here. If you know about source filters, you will see that the filter is very simple. Creating the source filter involves some strange idioms, I agree, but I can't be blamed for that. And adding some more comments should take care of instructing any other Perl programmers who take a look under the hood.

Traditional Perl modules have much lower odds of conflict.

I agree. But I see the source filter merely as a means of achieving the end now, as a prototyping tool, rather than as the way to do such a thing in the long run.

And so far nobody has commented on the API. So that at least feels right to the people who looked at this so far. I don't think there is a Perl 6 Apocalypse about this, is there?

Liz

[tilly]

Your opinions on what is and is not obvious clearly differ from mine. And breaking out the 50 pound sledgehammer of source filters, along with all of TheDamian's heuristics about how to interpret what is valid Perl (which you are quickly obsoleting), along with the potential bugs when TheDamian gets it wrong, doesn't strike me as a conceptually lightweight approach. Even when the piece that you added is simple.

Now if you want parametrized uses, consider the following (untested):

package load;
use Carp;
use strict;

sub as {
  my $pkg = shift;

  # Set the alias.
  $_[0] = $pkg;

  # load the module
  eval "require $pkg";
  die $@ if $@;

  # import it?
  shift;
  if (@_) {
    unshift @_, $pkg;
    my $import = $pkg->can("import")
      or croak("No import available to use");
    goto &$import;
  }
}

1;

This can now be used (assuming no bugs...) as follows:

use load;
Very::Long::Module->load::as my $short => qw(foo bar baz);

If you prefer a constant approach, that isn't hard to do either.

In any case the difference in ease of usage between these solutions and a source filter is pretty minor. The difference in potential problems is pretty large. (Note that I am steering towards solutions where you can create any aliases for yourself without trampling on any potential global namespace. That is both deliberate and, I feel, important.)

[liz]

Funny you put your example in the load namespace ;-). Or was that intentional?

I guess we agree to disagree. I find the syntax of

Very::Long::Module->load::as my $short => qw(foo bar baz);

very confusing. And a strange, roundabout way of setting $short.

...without trampling on any potential global namespace...

I think you touch on a very important flaw of my "as.pm" and of Package::Alias' approach as well. Consider a program which has:

use Foo;
use Bar;

Now, Foo.pm has the following shortening (using my syntax for ease of reading):

package Foo;
use Very::Long::Module::Name as Shorty;

and Bar.pm has the following shortening:

package Bar;
use Some::Other::Long::Module::Name as Shorty;

Then you see we have a problem. One of the two modules will be referring to the wrong long module name, depending on whether an existing stash would be overwritten or not. In other words: you can only have one Shorty. That's because the stash aliasing (or the @ISA assignment) is not limited to the package scope from which it is invoked. And I don't see a way to encapsulate it, as all of the object creation is at run-time.

In my view, this pulls the rug from under any shortening approach currently available. As you cannot create code that can be well-behaved in that respect.

Too bad. It was a nice idea while it lasted... ;-)

Liz

[dragonchild]

Wouldn't you have to transform Foo::Bar::Baz to Foo/Bar/Baz.pm, to make it work with require?