Re: LEOCHARRE:: modules and Wordpress::XMLRPC
Hi,
Jonathan Yu wrote:
> Dominique:
>
> Thanks for your insights!
>
> On Sun, Nov 22, 2009 at 6:36 AM, Dominique Dumont <domi.dumont@free.fr>
wrote:
>> Le samedi 21 novembre 2009 19:04:36, Jonathan Yu a écrit :
>>> What I am proposing is that we create a libleocharre-perl (better
>>> names welcome) and bundle all the LEOCHARRE:: stuff in there. That
>>> way, we'd be able to update Wordpress::XMLRPC without hurting the
>>> reusability of the LEOCHARRE stuff, but keeping in mind that these
>>> modules aren't likely to be used on their own (just as dependencies of
>>> LeoCharre's stuff).
>>>
>>> Thoughts all?
>> From a maintenance point of view, this is not good:
>>
>> - These module are not registered in CPAN name space (The LEOCHARRE:: name
>> space would never be accepted).
>
> I don't think this really matters anyway; these days few people use
> the CPAN module registration/module list thing. Most modules are
> "first-come" (meaning whoever uploads something with that module
> namespace gets it -- note, though, he doesn't own the entire
> LEOCHARRE* namespace; but it's doubtful anyone else would care to use
> it).
This is at least partly true. There's only two reasons why the modules
list still exists. None of them is that it is, by itself, very useful:
a) We, as PAUSE admins, want to give new contributors a reason to get
advice about their namespaces from experienced folks. Asking
module-authors@perl.org is actually better than modules@perl.org (more
eyes), but the registration may give this tiny bit of extra incentive to
ask. We're still looking for a way to get a similar effect without the
registration process.
b) Nobody has had the time to modify the PAUSE code base so that new
modules are auto-registered. There is a difference between "registered"
and "first-come" namespaces. The registered ones have extra meta-data
associated. We don't want to lose that.
Dominique is right to say that we would never register a namespace like
LEOCHARRE::*. The namespace choice should reflect the problem domain and
the author name has no business in code. If asked, we would strongly
discourage this practice. But it's for good reasons that such policies are
not strictly enforced.
Best regards,
Steffen
Reply to: