in reply to Re: DWIM: autoloading classes
in thread DWIM: autoloading classes

I can see from my original node that I (once again) was not terribly clear. The intent of this idea was to ensure that I had a general purpose module that I could point to any namespace and it would recursively travel through the directories (via File::Find or File::Find::Rule) and prepare those subroutines as I outlined above. Thus, I wouldn't have to change code in any of the classes found.

Further, by just adopting the syntax you listed in Re: The costs of packages, I think I might get exporting to work, also. What follows is a mish-mash of pseudo-code and Perl:

package Class::WhenNeeded;
use File::Find;

sub import {
    my ($class, $top_package, $no_top_level) = @_;
    my @dirs = map { find_top_level_dir($_, $top_package) } @INC;
    foreach my $dir (@dirs) {
        find({
            wanted     => \&create_package_sub($no_top_level),
            preprocess => \&perl_packages,
        }, $dir);
    }
}

sub create_package_sub {   
    my $strip_top_level = shift;
    my $module       = make_module_name($File::Find::name, $strip_top_
+level);
    my $call_pack    = (caller(1))[1];
    if (defined &{$module}) {
        require Carp;
        Carp::croak "Function $module already defined";
    }
    *{$module} = sub {
        undef *{$module};
        eval <<"        END_EVAL";
        package $call_pack;
        use $module; # export goes to calling package?
        END_EVAL

        if ($@) {
            require Carp;
            Carp::croak "Could not load module: $module";
        }
        return $module;
    }
}

[download]

Hopefully that clears things up.

Cheers,
Ovid

New address of my CGI Course.

Replies are listed 'Best First'.
Re: Re: Re: DWIM: autoloading classes
by BrowserUk (Patriarch) on Sep 17, 2003 at 03:15 UTC

    Your aiming at a somewhat different goal to me, in that my package don't exist as files and only come into being when they are used, but I really like where your going too.

    I'm not sure if it fits with your intent, but I really like the idea of 

    use WhenNeeded qw[
    HTTP::*
    HTML::*
];


my $headers = new HTTP::Headers;
...
my $request = new HTTP::Request;
...

my $content = decode( $content );

    [download]

    But maybe that syntax is just too Javan :)

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
    If I understand your problem, I can solve it! Of course, the same can be said for you.
[reply]
[d/l]
      But maybe that syntax is just too Javan :)

      Is that a problem? I would love to use WhenNeeded if I could, although it might be a bit tough to implement.

[reply]
[d/l]

        When I wrote that it was only half a joke. In Ovid's pseudo-perl examples above, he was just using 

        use WhenNeeded 'Foo';

        [download]

        but showed the Java syntax import foo.*; as an example of his inspiration.

        It struck me that as part of his pseudo-code involved using Find::File, that there might be some merit in using perl's globing behaviour to extend the Javan syntax and select subsets of a namespace. I then tried to look for a good example where using it would allow the selection of a realistic subset of an existing namespace, but couldn't find anything where more than foo::* (or I guess on non-dosish systems that would more properly be Foo::.*) would likely be used.

        At that point I realised that if the only common usage would be to select everything below a given point in the hierachy, then the * or .* becomes redundant and Ovid's original syntax would probably make more sense.

        I guess if the module was available, it might encourage authors to break up some of their bigger modules into smaller chunks spread across a deeper hierachy than is the norm? Which might lighten the load of some of them.

        I could perhaps see use CGI; being broken up so that you could do 

        use WhenNeeded 
    'CGI::HTML3::Table*',
    'CGI::Netscape::*'
;

        [download]

        And maybe 

        use WhenNeeded 'Date::Manip::EN::*';

        [download]

        So, no. I don't think that any resemblance to Javan syntax is really a problem, I just can't see a need for it currently, but that may mean I am limiting my imagination.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
        If I understand your problem, I can solve it! Of course, the same can be said for you.
[reply]
[d/l]
[select]

      That is an interesting idea, but fair warning: my tests reveal that "WhenNeeded" would break indirect object syntax. I can't think of any way around that without breaking more than I would fix.

      Cheers,
      Ovid

      New address of my CGI Course.

[reply]

        I'm not quite sure I follow how that would happen? I always thought that it was the compiler that dealt with the parsing and semantic analysis of direct and indirect object syntax. By the time your code is involved, it's just a method called with an object handle isn't it?

        I only use the indirect syntax for class methods rather than instance methods. I like the distinction, but I'm not locked into to it.

        I'm still unconvinced by the arguments against indirect object syntax. It seems that there are thousands of lines of perl written every day that use it with print and printf. The cavaeats are fairly clear and the solutions well documented.

        Personally, I'd like to see it's problems addressed so that I could make more use of it. We have prefix/ infix/ postfix operators for numbers. Why not other objects?

        I'd hate to have to write  3->-() for unary negation, or $n->predecrement(). And I can see many places where indirect object syntax could be used to great benefit. I don't use it (other than as outlined above) because of it's current limitations, but I think it would be a shame to see it's potential for clarity being thrown away. Maybe the parser could never be 'fixed' in this respect, and maybe there is a fundemental reason why it couldn't be made to work as well for the general case as it does for numbers. I don't have the experience with writing code parser to know, but instinctually, I'd like it if that were not the case.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
        If I understand your problem, I can solve it! Of course, the same can be said for you.
[reply]
[d/l]
[select]

In Section Meditations