Re: [Module::Build] M::B actions design

[Ken W. <ke...@ma...>]

On Thursday, October 16, 2003, at 09:57  PM, Randy W. Sims wrote:
>
> On 10/16/2003 6:50 AM, Steve Purkis wrote:
>> On Thursday, October 16, 2003, at 12:06  am, Randy W. Sims wrote:
>>> There is another issue here in that the list of actions is growing 
>>> quite large, and M::B is (IMHO) turning into a large monolithic 
>>> module. Would it be worth the effort to re-architect actions, so 
>>> that they are plug-ins (M::B::ACTION::html, M::B::ACTION::dist). 
>>> This would keep M::B from becoming monolithic and would allow others 
>>> to develop plug-ins to expand functionality without requiring 
>>> invasive code changes.
>> Yes, M::B: is becoming quite monolithic.  So was MakeMaker.  The main 
>> difference I find between the two is that M::B is much easier to 
>> read, understand and extend.
>
> I didn't realize until now that my original choice of words may have 
> been misconstrued as an insulting remark--That was not my intent. I 
> meant monolithic in the sense that most of the code is in a single 
> file/class (M::B::Base) that it is growing quite large, and it is not 
> likely to get smaller. I didn't intend it as an insult or as any kind 
> of judgemental statement, just as an observation.

Oh, I took no offense, and I think I would actually make the same 
criticism myself.  The monolithic nature of M::B is something I've been 
thinking about a lot (well, maybe just "some") lately.

A basic design stress in designing M::B was the following conflict:

  A) it should be easy to subclass, meaning that all methods should be 
part of a single class hierarchy

  B) it should be scalable, meaning that multiple classes should 
interrelate to accomplish tasks, and the user should be able to swap 
out different parts of the system with their own parts.

In the end I chose A).  A system like Mason uses B).  I think the trick 
now is to get the benefits of A) while incorporating some of the 
benefits of B), and I think a plug-in system could do that nicely.


>
> I don't know that I would describe MakeMaker as monolithic. Michael 
> Schwern has done a great job of cleaning it up. It's main problem is 
> that it is limited to the underlying tool--make, and to it's different 
> versions, implementations, and platforms.

Yeah, MakeMaker is sort of multi-monolithic.  Or Stonehengian.  ;-)

  -Ken