* brian d foy <[EMAIL PROTECTED]> [2007-03-03T13:31:15]
> In article <[EMAIL PROTECTED]>, Ricardo
> SIGNES <[EMAIL PROTECTED]> wrote:
> > extensions:
> > CPAN::Reporter:
> > cc_author: 0
>
> I think in some cases this might work, but I can imagine options that
> I'd want, such as cc_author, that future modules or tools might use. I
> won't know of them a priori, but it's likely that my answer to them
> will be the same.
If you don't know that CPAN::Reporter uses extensions/CPAN::Reporter/cc_author,
you won't know that it uses cc_author, either. While you might implement the
same solution, I think it's less likely that you'll settle on the same name,
and thus benefit from happy accidents.
...but maybe the benefit of the middle-level namespace there isn't so great,
and extensions/cc_author is good enough. I suppose that the chance of
collision of extensions is fairly low. This could be helped by having CPANTS
(or something) produce a listing of extensions actually used in the CPAN's
code, so you could see what else uses what. Collisions would be reduced to
times when modules introducing new extensions are uploaded at the same time or
when one author is careless.
If a feature becomes useful enough to be part of the core spec, then tools need
to know to look for ->{extension}->{yourface} or for ->{yourface}, which is
also annoying.
A solution might be to use purpose-named namespaces owned by other individuals
to manage common configuration, including a generic per-tool namespace.
test_reporting:
also_cc: [ [EMAIL PROTECTED] ]
indexer:
index_all: 1
extensions:
Module::Started: { built_by: '1.602' }
This lets people who will probably have common needs work together (hopefully)
without the META.yml spec maintainer worry about much besides "does this
deserve a namespace" and lets everyone use a namespace for their own little
tools.
I don't know, I'm just throwing the idea out there. These things are always a
pain.
--
rjbs
