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

However, the number of 'process' functions that I might generate are not limited, and that means that every time I add a new module with a new process, I'd have to modify the data type code in addition to add this feature, which is a nuisance.

Sounds like you might need a smart AUTOLOAD. Consider a scenario where you have a registry of "process functions" on disk, where the registry is a flat file database with pairs of "function-name, filename" as tuples. When AUTOLOAD is triggered, it scans this registry to locate the file that corresponds with a process function. When it finds one, it loads the file into a string, then evals it (as a sub definition) into the dataset's namespace.

This approach would let you (or others) write new process functions in files external to your main body of code. For extra credit, you could provide an option in your main script to use a different, "debug" registry that you would use for debugging new functions.

Here's an untested fragment, pieced together from pages 468-471 of the Cookbook.

sub AUTOLOAD { my $self = shift; my $attr = $AUTOLOAD; $attr =~ s/.*:://; # open the registry, search for $attr, # open assocated filename and load the # contents into $sub no strict 'refs'; *$attr = eval $sub; goto &$attr; }
Good lord, I just used a goto.

Replies are listed 'Best First'.
Re: Re: Possible Stupid Perl Trick - Importing method into object class?
by dragonchild (Archbishop) on Dec 07, 2001 at 22:48 UTC
    This is a good plan, however what do you do with a function that has a bug? I would be very loathe to do that kind of run-time evaluation of potentially tainted code in production.

    Better (and safer!) is to have everything there at compile-time, using import (as I said above).

    ------
    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.

Re: Re: Possible Stupid Perl Trick - Importing method into object class?
by dmmiller2k (Chaplain) on Dec 07, 2001 at 23:55 UTC
    Good lord, I just used a goto.

    If it makes you feel any better, the form you used isn't really even a goto, or at least not the way C/C++/Java programmers mean (i.e., the goto-LABEL form). Its use in AUTOLOAD subs is precisely what the goto-&NAME form was intended for.

    See this node: Would you use 'goto' here? for more on the topic.

    dmm

Re: Re: Possible Stupid Perl Trick - Importing method into object class?
by Masem (Monsignor) on Dec 07, 2001 at 23:05 UTC
    While this will probably work, it ends up with the same problem from the original idea: you have to maintain a repository of new functions which may be overlooked. That is, if I add a new processing step, I have to remember to add it to this file to make sure it works. Sure, as opposed to creating a new object method (and also remembering to import the new processing module), this is probably a bit easier, but again, it doesn't appear to solve the original problem.

    (And no, it's not the goto at the end of the code nor the lack of strictness that makes me wary of this method :-).

    -----------------------------------------------------
    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

      While this will probably work, it ends up with the same problem from the original idea: you have to maintain a repository of new functions which may be overlooked.

      You could skip the repository, and so something like

      if ( -f "$attr.sub" ) { # load and eval "$attr.sub" goto &$attr; }
      I used a registry so that you could stage the debugging of new functions. If that isn't an issue for you, then don't use a registry. I've used a registry for something like this in years past, and have found it useful, but YMMV.