in reply to Possible Stupid Perl Trick - Importing method into object class?

If you want to require "use MyCode::ProcessC" be added to the "data type" class, then that is just standard, run-of-the-mill Exporter.pm work with @EXPORT= qw( process_c ).

But it sounds like you want the "use MyCode::ProcessC" to be somewhere else. Since you are useing and not requireing, you could put the exporting code into MyCode::ProcessC::import (rather than a BEGIN block), which means that it would be called multiple times if you use MyCode::ProcessC multiple times. But that might be a good thing if you want to be "general purpose".

For example, you could require:     use MyCode::ProcessC( "DataType::Class" ); in the main script and have MyCode/ProcessC.pm contain: 

package MyCode::ProcessC;
use strict;
sub import {
    if(  2 != @_  ) {
        require Carp;
        Carp::croak( 'Usage: use ',__PACKAGE__,
            '( "DataType::Class" )' );
    }
    my( $self, $class )= @_;
    for my $meth (  qw( process_c )  ) {
        no strict 'refs';
        *{$class."::".$meth}= \&$meth;
    }
}

[download]

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: (tye)Re: Possible Stupid Perl Trick - Importing method into object class?
by Masem (Monsignor) on Dec 08, 2001 at 00:51 UTC
    This is definitely along the lines of what I'm looking for, and tested to make sure that it works with no problem. However, this is a large chuck of code that would need to be included in every possible process module.

    I've been trying to think of a way to place this in a parent class that the other process classes can inherit from, but there would seem to be a problem with the order of new, import, and the like that that I can't seem to find a way to get this to work.

    Again, VERY hypothetical code: 

    package My::ProcessC;

BEGIN {
    my @processfuncs = qw ( processC processC_alt );
}

use My::ProcessParent qw(register);

    [download]
    Alternatively, I'm wondering if modifying dws's idea above might be worth exploring. That is, add a register function to the DataType class, which stores what names are associated with with package and function, then have, in the process module's begin block, call that global-level function to register code. Then use AUTOLOAD in the DataType to handle those type of classes.

    -----------------------------------------------------
    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
    "I can see my house from here!"
    It's not what you know, but knowing how to find it if you don't know that's important

[reply]
[d/l]

      Well another alternative I proposed elsewhere was: 

      package My::ProcessC;
BEGIN {
    push @DataType::ISA, __PACKAGE__;
}

      [download]
      This is "reverse inheritance" (:

              - tye (but my friends call me "Tye")
[reply]
[d/l]
        tye++, but I posted because I felt a ++ was not enough here. Good thinking!
[reply]
      What's wrong with putting the import() function in some Process::Base class and having all your My::ProcessC whatevers inherit from it?

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

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]

        Yes, that has advantages and disadvantages. Having seen this done with things like Exporter.pm make me hate the idea (nearly every module in existance inherits a dozen utility functions from Exporter and lots of modules inherit AUTOLOAD that supports AutoSplit and just confuses people when they mispel a method name). Those problem don't apply to this case, at least not yet.

        One disadvantage is having to store the list of things to export in a global array with a magic name. I prefer something more like: 

        #!/usr/bin/perl -w
use strict;
use My::ProcessA( "DataType" ); # Defines: process_a() method
print DataType->process_a;

        [download]
        and then 
        package My::ProcessA;
use strict;
use ExportTo( [ qw( process_a ) ] );
sub process_a {
    "Do Stuff";
}
1;

        [download]
        and finally 
        package ExportTo;
use strict;
sub import {
    my( $self, $exports )= @_;
    if(  2 != @_  ||  ! ref($exports)
     ||  ! UNIVERSAL::isa($exports,"ARRAY")  ) {
        require Carp;
        Carp::croak( 'Usage: use ',__PACKAGE__,
            '( [ qw( func to export ) ] )' );
    }
    my $caller= caller();
    my $import= sub {
        if(  2 != @_  ) {
            require Carp;
            Carp::croak( 'Usage: use ',$caller,
                '( "DataType::Class" )' );
        }
        my( $self, $class )= @_;
        for my $meth (  @$exports  ) {
            no strict 'refs';
            *{$class."::".$meth}= \&{$caller."::".$meth};
        }
    };
    no strict 'refs';
    *{$caller."::import"}= $import;
}
1;

        [download]
        which ends up printing "Do stuff".

        Note that I pass the list of exports to ExportTo::import as a reference to an array because you might want to later get fancier with the interface such as allowing My::ProcessA to set the default class to export to. Likewise you can enhance the closure to support more self-documenting code like: 

        use My::ProcessA qw( DataType process_a revert_a );
# or even
use My::ProcessA( DataType=>[qw( process_a revert_a )] );

        [download]
        which I think is a great idea but that I didn't want to get into the somewhat complex @_-handling just because it would distract from the "point" I was making.

                - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]

In Section Meditations