On Fri, 2 Feb 2001, Jarkko Hietaniemi wrote:
> What I think is needed is some sort of opaque tag: the name of the
> 'contract' the API claims to fulfill. The name can be the name of
> the standard, the name of the company, the name of the individual.
> (Java does a very similar thing but they propose embedding the DNS
> name as part of the package name: I think they the right idea but
> the proposed implementation sucks.)
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;
There may be five modules implementing the 'CGI' interface, three for URI,
and two for HTTP. If it so happens that one module (CGI.pm, for example),
implements three of the interfaces I need, then that may be a better
choice than loading several separate modules. Or there may be a very fast
but less stable (or less portable) XS module for HTTP and a slower but
very stable and portable pure Perl version. They would have different
module names but would both implement the HTTP interface.
One thing this suggests to me is that part of the module install process
may include asking the installer what precedence they want to give the
module for each of the interfaces it supports.
The other question is how we define an interface (as opposed to how we
name it).
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
