use Perl

• please, no (Score:1)

  by perrin (4270)

  Sorry Ovid, but this is an abomination. It kind of sums up many of the problems with Perl culture: obsession with syntax over utility, willful use of obscure features like using the import list for other things, and a desire to make everything REALLY short. Give the module a normal name, call the alias method like a normal method, and give intermediate perl programmers a chance in hell of understanding your code. Otherwise, it belongs in Acme::.
  • Re:please, no (Score:2)

    by ziggy (25)

    I was going to post a flame about how the whole point of programming language design is to obsess over syntax in the name of achieving greater utility. That's what gave us idioms like 'open or die' and foreach loops over hand-compiling tail recursive forms.

    But I see that your clarification, and yes, the abuse of the import list is quite horrid.

    Perl is a dynamic language. There's no reason why the magic fiddling must happen at compile time, nor is there any reason why it the aliasing must use a use sta
    • Re:please, no (Score:2)

      by Ovid (2709) on 2005.01.05 12:30 (#37251) Homepage Journal

      Well, my thought is pretty straight-forward: the current code I have implemented not only works, it fits very naturally with current Perl syntax. I can't say that I like the syntax of how I handled importing, but that's not the common case. The important thing is that the common case be handled easily. The more programming people do, the more they want the common things to be short-n-sweet.

      My code is ready to be uploaded and I'm merely waiting for last minute objections from the modules@cpan.org list. If you can make a convincing argument why my solution is more abusive and how your solution is better, I'm willing to hear it. However, just saying that my abusing importing is a bad thing doesn't mean that it's a bad thing (no offense.) And just to give you a fair shot at making your case, here's the code I wrote:

      package aka;
      $VERSION = '0.1';
      
      use strict;
      
      sub import {
          my ($class, $package, %properties) = @_;
          require Carp && Carp::croak("You must supply a package name to aka")
              unless defined $package;
          my $alias  = $properties{as} || _get_aka($package);
          my @import;
          if (exists $properties{import}) {
              my $import = $properties{import};
              $import = [$import] unless 'ARRAY' eq ref $import;
              @import = @$import;
          }
          unshift @import => $package;
          my $callpack = caller(0);
          {
              local $SIG{'__DIE__'};
              eval "package $callpack; require $package; sub $alias { '$package' }";
              die $@ if $@;
          }
          my $import_method = UNIVERSAL::can($package, 'import');
          @_ = @import;
          goto $import_method if $import_method;
      }
      
      sub _get_aka {
          my $package = shift;
          $package    =~ s/.*(?:::|')//;
          return $package;
      }
      
      1;

      The only reservation I have is about my use of UNIVERSAL::can. It's possible that a package (or a subclass prior to UNIVERSAL) has implemented its own &can method, but I think this is so obscure a case that I'm not too worried about it. On the other hand, I did allow for single quote marks in package names :)

      Reply to This

      Parent

      • Re:please, no (Score:1)

        by chromatic (983)

        The only reservation I have is about my use of UNIVERSAL::can.

        As well you should. The right code is even shorter and clearer.
        • Re:please, no (Score:2)

          by Ovid (2709)

          Silly me. For some stupid reason I thought I shouldn't use $package->can('import') because there's no guarantee that there's an import method. Mentally I thought "there's no guarantee that package can('can') and that might throw an error." It's weird how muddled my mind substituted "can" for "import" in that method call :/