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

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.

Replies are listed 'Best First'.
Re: Re: Re: Re: DWIM: autoloading classes
by jryan (Vicar) on Sep 17, 2003 at 07:41 UTC
    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]
Re: Re: Re: Re: DWIM: autoloading classes
by Ovid (Cardinal) on Sep 17, 2003 at 15:56 UTC

    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