[EMAIL PROTECTED] (Andreas J. Koenig) writes:
> >>>>> On Fri, 26 Jan 2001 16:37:23 -0500, Michael G Schwern <[EMAIL PROTECTED]> said:
>
> > from what I remember we discussed
> > an idea to allow people and organizations to produce their own list of
> > approved modules.
>
> This is already possible with the CPAN::Site module.
>
> > For example, if Oracle had their own QA people
> > approve a set of modules and versions allowed for use in their
> > company. These lists would be archived and made available just like
> > CPAN is now. A subclass of the CPAN shell could be built allowing the
> > user to specify which organizations they trust and it would only pull
> > modules from there.
>
> This description goes a bit beyond CPAN::Site's abilities.
>
> > This isn't *quite* what most people are thinking of, and it in no way
> > addresses the problem of having multiple versions of the same module
> > installed on a given machine, but it does allow people to pick and
> > choose between implementations without fragmenting CPAN.
>
> Larry mumbled something like "implements" and "interface". So to say
>
> package Net::FTP::Foo implements Net::FTP;
>
> But I don't think, anybody wrote an RFC about the plan.
I did. Or something like it. And I've got a couple of modules on CPAN
(that I really must document better) that kind of work already:
package ShoppingBasket;
use ex::interface qw/add_entry total_price delete_entry .../
1;
package Vendor::ShoppingBasket
use ex::implements ShoppingBasket
...
Which does nice compile time tricks to ensure that everything in the
interface has been implemented.
It's 5.6.0 only, and it currently tries to do too much (must cut it
down), but I've found it surprisingly useful.
Of course, the likes of CPAN takes no notice of it, and unless we
start having some kind of module registry it's going to be hard to do:
use ShoppingBasket;
and have that import the local implementation of same...
--
Piers
