[ 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

Reply via email to