gmane.comp.lang.perl.modules.authors

Idea for a module: Test::Prereq::MiniCPAN

Robert Rothenberg — 2012-05-18T14:41:49

This module would be based on Test::Prereq, but instead of looking in a
Makefile.PL, it would look in a Mini-CPAN (based on the CPAN, CPANPLUS
configuration) and see if the module was specified in the 02packages list.

RFC: Arduino::Pseudo

Aldo Calpini — 2012-05-04T13:28:39

hello CPAN fellows,

I'm toying with Arduino lately, and I wrote myself a sort of Arduino 
pseudocode simulator. in Perl :-)

basically, it's just a Wx::App which tries to mimic the working of an 
Arduino, with visible widgets for physical components like pushbuttons, 
leds and potentiometers.

it's still very rude and the GUI is not visually pleasant, but I found 
it moderately useful so far.

I have setup a quick page which shows some synopsis code and explains a 
little bit better what the module does:

http://dada.perl.it/Arduino-Pseudo/

the questions:

a) do you think it's worth a CPAN upload, or better keep it in the crazy 
ideas drawer? :-)

b) do you think the name Arduino::Pseudo fits?

I know there is the Device::Arduino namespace already, but since this 
has really nothing to do with the actual physical device, I don't think 
it should be in Device::.

on the other hand, it would be a new top-level namespace, which maybe 
someone won't like. I'm open to suggestions.

cheers,
Aldo

removal request - Sys::UniqueID

Daniel Lukasiak — 2012-04-24T17:05:23

Hi all,
while I was browsing CPAN I found Sys::UniqueID which I think should be 
removed from CPAN for several reasons:
1. It doesn't compile (hostip isn't exported by Sys::HostIP
2. It doesn't do what it says in the docs, even when I replaced hostip 
with ip it didn't work (returns empty string)
3. Author's email address is dead.||
4. No updates since 2000 (not a problem by itself, but see 1 and 2)

Given there's Data::UUID which is a better alternative (even to working 
Sys::UniqueID) I think it's reasonable to remove Sys::UniqueID from CPAN.

If removal isn't possible is there any other mechanism (forced 
depreciation?) that can be used?

Daniel

Contacting Tassilo von Parseval about adopting Inline::Lua

Shlomi Fish — 2012-04-23T09:11:39

Hi all,

Rob Hoelz has written this blogs.perl.org post about his willingness to
contribute to Inline::Lua by contacting the original author :

http://blogs.perl.org/users/hoelzro/2012/04/still-alive-inlinelua.html

Quoting from it:

[QUOTE] 

I was reading about the Inline module the other day, so naturally I looked to see if there was a binding for one of my other favorite languages, Lua. Sure enough, Inline::Lua exists; however, it has not seen a new release in nearly five years, and it doesn't even build on perls newer than 5.10. I like this idea enough that I'd like to put some time into it and cut a new release; however, I haven't been able to reach the author. So, in accordance with the guidelines I read in the CPAN FAQ, I'm making a post asking if the original author, Tassilo von Parseval, is still in the Perl community and interested in updating this module.

[/QUOTE]

There's also a useful comment by Joel Berger with some leads.

Regards,

Shlomi Fish

RFC: Name for new modules (RandomJungle::)

Robert Freimuth — 2012-04-15T02:27:33

<resending from a gmail account after failed attempts from a yahoo account
- apologies for duplicate postings if the first ones eventually come
through)

Hi,

I developed a series of modules that provide users with the ability to
post-process and manipulate the output of the Random Jungle program (
http://randomjungle.sourceforge.net/).  The proposed name of each module,
as well as a brief synopsis, is included below.  Please let me know if more
information is desired.

I would appreciate input on the selection of names.  At last check, there
was nothing on CPAN related to Random Jungle.

Thanks,
Bob

There are 7 modules in this distribution, 4 of which provide low-level
access to files and 3 of which are intended to be used by client programs.

Modules to access RJ data files:

RandomJungle::File::XML - Low level access to the data in the RandomJungle
XML output file

RandomJungle::File::RAW - Low level access to the data in the RandomJungle
RAW input file

RandomJungle::File::OOB - Low level access to the data in the RandomJungle
OOB output file

RandomJungle::File::DB - Low level access to the data in the RandomJungle
DB file (used to consolidate data from the XML, RAW, and OOB files and
provides query methods)

Modules to provide a user-centric interface to RJ data:

RandomJungle::Jungle - Consolidated interface for Random Jungle input and
output data (from the perspective of the entire jungle)

RandomJungle::Tree - A Random Jungle classification tree (trees make up the
jungle)

RandomJungle::Tree::Node - A simple representation of a node in a
RandomJungle::Tree

New DMTF module set with proposed top-level namespace

Stephen Hurd — 2012-04-10T18:45:27

I'm working on a set of modules which implement various DMTF standards.  Mostly they are alphabet soup, but my proposal for the module names is:

DMTF::CIM - Working with a DSP0004 CIM (Common Information Model) object model
DMTF::WSMan -The WS-Management protocol (DSP0226)
DMTF::CIM::MOF -MOF (Managed Object Format) parser (format defined in DSP0004)
DMTF::CIM::WSMan - Maps WSMan traffic to CIM data (DSP0227 and DSP0230)
DMTF::SMME -SM ME (DSP0215) UFiP expansion

Most of these modules are currently fairly light, but have room for growth and are interrelated and interdependent.  I initially considered a more abstract top-level namespace such as "Management" but that would make the association between the WSMan and CIM modules unobvious and already existing things such as SNMP:* and Net::SNMP are already in separate namespaces.  These module names are a bit of an alphabet soup, but most pass the "Google Test" and are obvious to people who would want to make use of the standards.

Future modules which are but a glint in my eye:
DMTF::ASF - Module for working with ASF (Alert Standard Format) traffic (DSP0114)
DMTF::ASF::RMCP -RMCP (Remote Management and Control Protocol) protocol (defined in DSP0114)
DMTF::ASF:: PET - PET (Platform Event Trap) protocol (per DSP0114, defined by Intel)
DMTF::CIMXML - The CIM-XML protocol (Defined in DSP0200)
DMTF::CIM::CIMXML - Maps CIM-XML traffic to CIM data (DSP0201)

The module naming doc makes it relatively clear that grabbing a top-level namespace without discussion is frowned upon, so I want to get this discussion rolling.

Stephen Hurd
Senior Staff Engineer - Software Development
Broadcom Corporation
949-926-8039
shurd< at >broadcom.com<mailto:shurd< at >broadcom.com>

Changing module name

Zbigniew Łukasiak — 2012-04-09T11:23:07

I am thinking about changing Plack::Middleware::Auth::Form to
WebPrototypes::LoginForm - the idea is to provide more such 'widgets'
(there are already two published:
http://search.cpan.org/search?query=webprototypes&mode=all - still
experimental) with the same basic approach for  reusabillity of web
elements.

Is there a common procedure for such a migration?

The Marpa namespace

Jeffrey Kegler — 2012-03-24T03:01:08

[ This post, from the marpa parser Google group (https://groups.google.com/forum/?hl=en&fromgroups#!forum/marpa-parser) largely repeats what I believe to have been the result of a previous discussion in this group.  I send it now because I know of several Marpa-based modules being created, suspect there are others, so that I think it may be timely.  Thanks.]

The standard and traditional practice is, where a module or set of modules is associated with a top-level namespace, to reserve that namespace for modules controlled by a single team.  The example cited most often is Moose, which top-level namespace is reserved for modules controlled by the Moose Team.  Moose modules not under the control of the Moose Team often go into the MooseX namespace, which is reserved for that purpose.

I feel that I need to follow this practice for Marpa.  Modules going into the Marpa top-level namespace should only be those completely controlled by the Marpa Team.  Among the places where other Marpa-related modules can go is into a top-level MarpaX namespace.

I don't know the full history of the traditional practice, but there are at least two reasons why it is necessary in the Marpa case.  The first is namespace management.  The Marpa Team, to avoid collisions, and for its own expansion needs, requires a namespace that it controls fully.  A second reason is least surprise when it comes to responsibility for the modules and issues with them.  A user will have a reasonable expectation that, if there is an issue with a Marpa::X::Y::Z module, the Marpa Team are the people to go to about it.

Under traditional practice, the Marpa Team is also entitled to control all namespaces with Marpa as a component, for example, Acme::Marpa::Widget.  The Marpa Team will NOT exercise this traditional right.  The Marpa Team feels that control of the top-level Marpa namespace is sufficient.  The usual PAUSE and CPAN processes for granting namespaces, of course, still apply, and there may be cases where the Marpa Team wants input into those processes.

In the above, I refer to the "Marpa Team".  At the moment, this is simply me.  Other projects of the size and complexity of Marpa are managed by multi-person teams, and I hope that will become the case with Marpa.

Thanks, jeffrey kegler

Proposal for building module info

Neil Bowers — 2012-02-10T09:47:56

Hi,

At the start of each CPAN module review I do, there is a table of summary information for all the modules reviewed. Ron suggested that the module which builds up this information be released to CPAN. See an example at http://neilb.org/reviews/constants.html

At the moment this is part of the mash of code I use to construct the reviews, but I could pull it out to a small distribution, which would probably have two modules in it:

One which talks to MetaCPAN, gets the RT summary file, and talks to the CPAN dependencies service.
The other which is a data object, one per module. 

At the moment I have everything internally under a CPAN::Curation:: namespace, but if released separately I don't think that's appropriate.

CPAN::Module::Metadata for the data class?
CPAN::Module::GetMetadata for the builder? CPAN::Module::Metadata::Factory?

I don't really like the second name, but can't think of a better one off the cuff.

There are a number of modules which do related things, but I couldn't find one which does this, when I started. Questions:

Is there an appropriate module / distribution that this could be fit into?
Does this make sense to have as a separate dist?
What are good names for the two classes?

cheers,
Neil

metacpan logo contest voting?

David Nicol — 2012-01-31T02:09:54

I like
http://entries.contest.metacpan.org/2012/01/andy-walker-3.html
the best but it isn't clear how to register this, aside from giving it a
Google plus point.

Finance::OFX is missing

Brandon Fosdick — 2011-12-30T19:00:31

Well, it's sort of missing. It's still listed on search.cpan.org (http://search.cpan.org/~bfoz/Finance-OFX-2/lib/Finance/OFX.pm) but I got a report from a user that CPAN says that it's unavailable. I tried it myself and got:

10:13 bfoz< at >BrandonMBP~%sudo cpan install Finance::OFX
...
Running install for module 'Finance::OFX'

  The module Finance::OFX isn't available on CPAN.

  Either the module has not yet been uploaded to CPAN, or it is
  temporary unavailable. Please contact the author to find out
  more about the status. Try 'i Finance::OFX'.



It was working last time I tried it (admittedly, not recently) and everything looks ok to me in PAUSE, but I really have no idea what to check for. This is the first time I've had this problem. Any suggestions?

looking for Jonathan R. Warden (JOHNWRDN)

Neil Bowers — 2011-12-23T00:59:15

Does anyone know (how to contact) Jonathan R. Warden, the author of constant::Atom, which is his only distribution on CPAN.
Email to his contact email address bounces, and attempts to track him down via LinkedIn, facebook etc.

I'm writing a review of modules for defining constants, and in doing so found and fixed a bug in constant::Atom.

thanks,
Neil

Net::Evernote

Ken Peng — 2011-12-15T01:33:08

Hi,

I just created a project on CPAN Net::Evernote, it's the most original
0.01 version.

http://search.cpan.org/~yhpeng/Net-Evernote-0.01/lib/Net/Evernote.pm

Evernote's API is a big collection of functions, I don't have that
much time to implement all of them.

If you anybody has the interest with this project, please let me know,
we could co-work with it.

Thanks.

Ken.

Naming of Perl module

2011-12-13T16:21:37

Hi there,

I'm close to completing a module, but I'm pretty clueless on what to call it. 

The purpose of the module is to find files which match a regular expression. The module currently only has one subroutine which takes two parameters, base_directory and expression. The subroutine traverses all subdirectories of the base directory and returns a hash when it's completed. 

Each key of the returned hash is the absolute path of the directory, and the value(s) associated with the key are the files which were found matching the regular expression within that directory, the hash only returns a directory if there are files which matched the given regex found within that directory. 

I've had a couple of ideas such as File::Snap (based on a card game I used to play as a child), but I'm not sure if it's very suitable. Any guidance would be appreciated.

Many thanks, 
Lloyd.

Looking for nightcat (LINC)

Neil Bowers — 2011-12-13T00:49:44

Hi,

Does anyone have contact details, or even know the name of Nightcat (PAUSE id LINC)?
(S)he has three dists on CPAN, including HTTP::Client. I've fixed a number of bugs in HTTP::Client,
and mailed the address registered with PAUSE, but that results in a bounce (no such mailbox).

None of the dists give Nightcat's name, so I'm drawing a blank on tracking him/her down.
I've emailed postmaster at his registered address, to see if they can give me a forwarding address.

PAUSE admins: if that turns up nothing, I'll ask for co-maint.

Neil

Module naming: postifx/dovecot/MySQL configuration

Avi Greenbury — 2011-12-13T13:06:32

Hi,

I've been working on a module which basically makes it easy to write
command-line tools for interacting with a postfixadmin[0] installation,
that is a Postfix/Dovecot mail server with virtual domains/users stored
in MySQL. I'd like to upload it to the CPAN, and I'm after some advice
on what to call it first.

The closest I can find on the CPAN is VUser::Email::Postfix which is
part of VUser. 

There's also Mail::Vpopmail which is exactly the same in purpose, but
for Vpopmail rather than postfixadmin.

To me, this obviously belongs somewhere in the Mail namespace, but I'm
not really sure where it should go in that. I'm tempted to rename it to
Mail::Postfixadmin, but I don't want to give the impression that it's
somehow endorsed by that project.

It's currently called Mail::Vpostmail (since originally it was to be a
postfix clone of the Vpopmail utilities and it must have seemed like a
reasonable pun at the time).

I've got a bunch of work to do on it over Christmas, and I figure that
that's also as good a time as any to rename it in preparation for making
it more public and check everything still works.

Thanks!

Looking for Sean Cannon (DODGER)

Neil Bowers — 2011-12-12T00:41:54

Hi,

Does anyone know how I can contact Sean Cannon? His PAUSE id is DOGER, and he has several dists on CPAN, including Geo::Coder::HostIP, which I've fixed a few bugs in.

Neil

Module Naming for Perl Reference Object Lookup

mark — 2011-11-26T04:39:06

Hello people of module-authors!

I have been working on a module which will allow one to do some 
relatively advanced storage and lookup mechanisms
on pure Perl object references.

The features are as follows:

1) Use perl objects as keys.
2) You may choose whether the database will retain a strong or
     weak reference to either the key or the value
3) You may store a single value under multiple keys; keys may be of 
mixed type
4) Reference keys and objects may optionally be deleted when their 
referrant objects are destroyed
5) Store multiple value objects under 'tags' or 'attributes', these tags 
themselves may be either
     strings or references
6) Multiple deletion options, delete all keys/attributes
     by a value, delete a value by any given key, delete
     any values for a given attribute, delete an attribute lookup, 
dissociate an attribute from
     a value
7) Elegant debugging/dumping information, showing a lower level view of 
the lookup table
8) Uniform API with two currently implemented backends (one is my XS 
code, other uses Variable::Magic)
9) Unlike Hash::Util::FieldHash, this module will work with perl 5.8.8 
(the version used in EL5-based distributions)
10) Decent speed, using an intel xeon E5520 CPU, i was able to acheive 
200k store/sec for string keys, 150k store/sec for object keys, and 50k 
store/sec for attribute lookups. At best this is still a good 6-7 times 
slower than a normal perl hash, but is still
acceptable.

An example usage module (poco-keepalive) is available here:
https://github.com/mnunberg/Hash-Registry/blob/master/examples/poco-component-keepalive.pm

Implementation details ae here:
https://github.com/mnunberg/Hash-Registry/blob/master/Guts.pod

Basic API interface is here:
https://github.com/mnunberg/Hash-Registry/blob/master/api_list.txt

and of course, you should be able to determine where the rest of the 
stuff is, if you wish to look into it a bit more.

Anyway, the question I wish to ask is in respect to naming this module;
I have had several ideas for naming this, all which are unacceptable;
The current name (Hash::Registry) was randomly chosen when this project 
was still just hoping to be some kind of tied hash

Another idea was Data::Registry or Object::Registry, but this makes the 
module sound like it's dealing with actual 'data'
rather than perl references, while the emphasis is very much on opaque 
perl references (such as globrefs, etc.) rather than even trying to make 
an attempt to deal with actual 'data' (that is, serialization, 
inspection of object methods etc. etc.).

Another name that came up was Data::RefDB, which is a bit inelegant, and 
sadly, anything with the name 'DB' in it seems to imply something of an 
RDBMS or at least something with serializing and persistent storage 
(while my module wants nothing to do with either).

The name that's been sticking with me for a while has been 'Prod', or 
Perl Reference Object Database. But, it's a top-level namespace and 
someone commented that it gives the impression of having something to do 
with POD, so I'm quite lost.

Another thing to note is that I will probably want to publish a few more 
modules under this namespace; at least one comes to mind, and that is 
::Trigger, which will provide a common PP and XS interface for 
performing various actions on C<free> magic, such as calling a CV, 
deleting a hash entry or array element, or even calling a C function 
(the XS implementation already provides the API and I just need to tidy 
it up a bit), and would be a far higher performing substitute for common 
cases of DESTROY

__END__

Synopsis:

=head1 SYNOPSIS

     my $table = Hash::Registry->new();

Store a value under a simple string key, maintain the value as a weak 
reference.
The string key will be deleted when the value is destroyed:

     $table->store("key", $object);

Store C<$object> under a second index (C<$fh>), which is a globref;
C<$fh> will automatically be garbage collected when C<$object> is destroyed.

     {
         open my $fh, ">", "/foo/bar";
         $table->store($fh, $object, StrongKey => 1);
     }
     # $fh still exists with a sole reference remaining in the table

Register an attribute type (C<foo_files>), and tag C<$fh> as being one 
of C<$foo_files>,
C<$fh> is still dependent on C<$object>

     # assume $fh is still in scope

     $table->register_kt("foo_files");
     $table->store_a(1, "foo_files", $fh);

Store another C<foo_file>

     open my $fh2, ">", "/foo/baz"
     $table->store_a(1, "foo_files", $fh);
     # $fh2 will automatically be deleted from the table when it goes 
out of scope
     # because we did not specify StrongKey

Get all C<foo_file>s

     my < at >foo_files = $table->fetch_a(1, "foo_files");

     # < at >foo_files contains ($fh, $fh2);

Get rid of C<$object>. This can be done in one of the following ways:

     # Implicit garbage collection
     undef $object;

     # Delete by value
     $table->purge($object);

     # Delete by key ($fh is still stored under the foo_keys attribute)
     $table->purgeby($fh);

     # remove each key for the $object value
     $table->unlink("key");
     $table->unlink($fh); #fh still exists under "foo" files

Get rid of C<foo_file> entries

     # delete, by attribute
     $table->purgeby_a(1, "foo_files");

     # delete a single attribute from all entries
     $table->unlink_a(1, "foo_files");

     # dissociate the 'foo_files' attribtue from each entry
     $table->dissoc_a(1, "foo_files", $fh);
     $table->dissoc_a(1, "foo_files", $fh2);

     # implicit garbage collection:
     undef $fh;
     undef $fh2;

The CPAN Covenant

Neil Bowers — 2011-11-17T08:13:45

A week ago I posted a proposal for a voluntary pledge, which CPAN
module authors could sign up to. With Bill Ward's tweak to the wording,
the discussion on per-distribution stating, and generalising the RT point:

   I hereby give modules< at >perl.org permission to grant co-maintainership
   to [% distribution %], if all the following conditions are met:

   (1) I haven't released the module for a year or more
   (2) There are outstanding issues in the module's public bug tracker
   (3) Email to my CPAN email address hasn't been answered after a month
   (4) The requester wants to make worthwhile changes that will benefit CPAN

   In the event of my death, then the time-limits in (1) and (3) do not apply.

In the discussion on module-authors, and talking to people at the London
Perl Workshop (LPW): about 60% thought it was a good idea, 20% a bad idea, and
20% indifferent. Most of the 'bad' being "it works that way already".

Talking to people at LPW, a number commented (paraphrasing):

    Just email the author, wait a month,
    then push modules< at >perl.org for a handover

Which to me doesn't quite match the spirit of the PAUSE "taking over" process
described at http://pause.perl.org/pause/query?ACTION=pause_04about

I recently took over a module after 2 months, during which I tried a number
of ways to track down the author, mailed various other people, and posted
to module-authors. That seemed appropriate, because the author had clearly
put a lot of thought and effort into this, and his other modules.

So, I went to Andreas Koenig, since he has more experience of module handovers
than most of us! The group behind modules< at >perl.org have to balance two sides:
respecting individual authors, and helping the continued development of CPAN.
If none of the group know the current author, they have to err on
the author's side, not CPAN:

    "I've heard too many upset developers going berserk because they felt
     [their module was expropriated]"

Asked whether he thought an explicit pledge would be useful, Andreas said:

    "An explicit statement in a distribution like the one in your picture
     would make our lives a lot easier"

As a number of others commented, Andreas feels it should be stated on
a per-distribution basis, and not per-author.

In a side-discussion, it was pointed out that sometimes an author would
be happy for someone else to take over the module.
In this case the covenant would become:

   I hereby give modules< at >perl.org permission to grant lead authorship
   to [% distribution %], if the following conditions are met:

   (1) There are outstanding issues in the module's public bug tracker
   (2) The requester wants to make worthwhile changes that will benefit CPAN

There are at least three ways this could be provided:

    (a) a file included in the distribution. Eg Covenant.txt
    (b) text in the README
    (c) a feature on PAUSE, where you can select the "ownership status"
        or similar

The problem with (c), is that it's not very public; the information needs
to be closely associated with the distribution itself. To make things
easy for all involved, I think (a) is probably the best. The downside with
this is that having lost interest in one of your distributions, you now
have to do a release to let the (Perl) world know. The alternative would
be to email the covenant to modules< at >perl.org: that's publicly archived,
so your covenant could be found, especially once a convention
has been established.

The module authors pledge

Neil Bowers — 2011-11-08T16:22:02

One of the problems I see with CPAN is that there are many modules
which have been left unattended. Many of these have outstanding bugs,
and a good number have patches and forked versions, some of which you can
find on RT. You'll also find people offering to take over the maintainership
of modules. While reviewing modules I've identified a lot of fixes, and 
documentation improvements, but it can take a lot of effort to get them out.

If the author or current maintainer of a module is unresponsive, there's
a well-defined, but lengthy, process to request co-maintainership. 
There are good reasons for this -- I'll assume you've read them.
But in reality, plenty of authors lose interest

To make life easier for the perl modules cabal, how about a voluntary
pledge[*], which module authors can take publically, and in particular
can take to modules< at >perl.org. I'll be emailing the following to
modules< at >perl.org:

    I hereby give modules< at >perl.org permission to grant co-maintainership
    to any of my modules, if the following conditions are met:

    (1) I haven't released the module for a year or more
    (2) There are outstanding issues on RT which need addressing
    (3) Email to my CPAN email address hasn't been answered after a month
    (4) The requester wants to make worthwhile changes that will benefit CPAN

    Should I die, then the time-limits in (1) and (3) do not apply.

This means it will be archived, and easily accessed. I'll put this in the
README for my modules.

If others, and particularly the modules cabal, think this is a good idea,
maybe we could have a canonical place this this, which can be easily
referred to. Perhaps PAUSE could let me record it, so there's one place
the modules cabal can check? Or you could put it in module metadata?

So, what do y'all think?

Neil,
in the light of recent discussions, donning flame-retardent long-johns.

[*] I tried to come up with a catchy name for this, but failed. Ideas?

New module naming

Trystan — 2011-11-06T21:42:58

Hi. I've written few libraries I'd like to release on CPAN and I'm looking
for some advice on how to name them.

I found this idea in Head First OOA&D<http://headfirstlabs.com/books/hfooad/>,
chapter 5. It's somewhat like a very simple version of Key-Value
Coding<http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html#//apple_ref/doc/uid/20001838-SW1>.
It's also very similar to
Object::Generic<http://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pm>but
I didn't use AUTOLOAD and I implemented 'equals' and 'contains'
methods
in order to make the objects searchable within a container.

Here's an example:

 my $a = tbd_name::Object->new();
 my $b = tbd_name::Object->new();

 $a->set( "ID", tbd_name::String->new("1234a") );
 $b->set( "ID", tbd_name::String->new("1234a") );

 print $a->get("ID");

 $a->equals($b) ? print "yes";

 $container = tbd_name::List->new();
 $container->add($a);

 $container->search($b);  #which returns $a

What do I call this thing? I'm thinking the namespace would be 'KeyValue::'
or 'KeyVal::' Would that make sense? (That namespace doesn't seem to be
used.) Should this go in 'Class::'?

Thanks.