Instead of saying "needs CGI;" try saying "needs DBI;" and see how it
thinks.
I think it works okay to split the problem into "declares (and does
some work)" and "defines", then maybe override the same set of words to
do this (to keep the degree of difficulty up).
Figure that "core" interfaces are too important to leave to chance. So,
let the existing trust mechanisms deal with that. But we want to be
able to specify interfaces and then rewrite the internals. Great. Steal
a page from DBI and let one module define the interface and some glue
to interact with a "helper interface" and then let the hoi polloi code
to the helper interface.
If someone wants to recode the "core" interface, that's okay. But they
have the chore of putting it on CPAN and convincing others that it
works and is better than the "default".
In the meantime, if I want to write some bizarre interface that makes
total sense in my context but maybe nobody else cares about, I can
leverage the interface capability and "trust myself" for updates.
Best of all, I'm sure there'll be some kind of "here's a generic
interface-implementer" module, a la Class.pm, maybe "Interface.pm". I
use that and I'm up and running, viz:
scp.pm
==========
package SCP;
provides SCP v.1.0;
use Interface::Generic;
... Damian Conway can fill this in later, less the SCP details :-> ...
----------
Then later:
scp_nortel.pm
==========
package SCP::Nortel;
provides SCP::Implementation v.1.0;
... Some telcom geek writes this ...
----------
Finally:
softswitch.pm # <-- (You know it's going to happen eventually...:-)
==========
needs SCP;
... Some (possibly other) telcom geek writes this ...
----------
=Austin
--- Nathan Wiger <[EMAIL PROTECTED]> wrote:
> 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
=====
Austin Hastings
Global Services Consultant
Continuus Software Corporation
[EMAIL PROTECTED]
__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
