Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

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

by liz (Monsignor)
on Oct 14, 2003 at 16:12 UTC ( #299167=note: print w/ replies, xml ) Need Help??


in reply to Re: use Very::Long::Module::Name as Foo;
in thread use Very::Long::Module::Name as Foo;

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


Comment on Re: Re: use Very::Long::Module::Name as Foo;
Select or Download Code
Re: Re: Re: use Very::Long::Module::Name as Foo;
by tilly (Archbishop) on Oct 14, 2003 at 17:02 UTC
    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.)

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

      ------
      We are the carpenters and bricklayers of the Information Age.

      The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

      ... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        No, because it is a source filter. It changes source such as:
        use Very::Long::Module::Name as Foo;
        to:
        BEGIN {*{"Foo::"} = \*{"Very::Long::Module::Name::"}}use Very::Long::M +odule::Name;
        essentially aliasing the stashes of the Foo namespace with the Very::Long::Module::Name namespace at compile time.

        So this is before anything is required under "use"s hood.

        Liz

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

        No. That was the point of the string eval.

      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

        Re-using load was not intentional, I was just looking for a name that made that line read relatively nicely, and I was in a hurry because I was late for work.

        As for the shortening approach, putting the package name in a variable works reasonably well. Putting the package name in a constant somewhat works. Both will work with the direct syntax, but not the indirect, my differing judgements on them are that people who don't understand the magic are (at a guess) more likely to accept the syntax error from the variable than from the constant. That is:

        my $short = 'Very::Long::Module'; use constant Short => 'Very::Long::Module'; # Later the following work: $short->new(@args); Short->new(@args); # The following do not: new $short(@args); # I'm guessing unsurprising? new Short(@args); # Possibly puzzling?
        It would, I guess, be possible to use source filtering to both set a constant and to rewrite indirect method calls. I wouldn't trust it too much though...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://299167]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (9)
As of 2014-12-23 03:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (135 votes), past polls