Dave Rolsky wrote:
>
> That's what I was thinking. The point is that the module identifies the
> services it provides. Multiple modules may provide overlapping sets of
> services. Modules could also be somehow ranked (memory usage and speed
> come to mind).
>
> Then I could put this into my module:
>
> needs CGI;
> needs URI;
> needs HTML::Output;
> needs HTTP;
First off, let me say that I like the autoloading idea, and tying it in
with class contracts, and all that in theory.
However, it also seems that this is getting *really* complicated really
quickly.
At some point I wonder whether this is more effective than just telling
people "Look, sockets and formats have moved out of core. Deal. You now
have to use Format and use Socket".
I like the concept of autoloading, but there's also some major concerns
(many of these are harvested from the RFC 153 discussions):
1. Site dependency. Currently, if you "use Blarf" and
Blarf.pm isn't at another site, you get a very
explicit and easily-understandable error message.
How is this handled above? This ties into...
2. Maintainer dependency. How and who maintains the
golden list of what a "CGI" interface is? This
must be a strict, global definition to really work.
For example, if I claim to support "CGI", do I really?
What if Bob's and Jim's "CGI" interfaces are different,
and Perl imports a module that claims to but doesn't
really support the "CGI" that I need?
3. User dependency. How does this interact with 'use'?
Does 'use' win? What if 'use' and 'needs' (or whatever)
don't overlap correctly, and I get multiple param()'s?
Who wins?
I know nobody's suggesting we get rid of 'use'. But if we did some type
of autoloading thingy, it would be nice if it were cool enough to
obviate the need for it. But I worry the above is going to be so
incredibly bloated and complex that it's unstable and unusable.
Or am I way off?
-Nate
