[development] Module Builder Module 1.0

[Bertrand Mansion]

Larry Garfield wrote:

>On Tuesday 21 February 2006 07:26, Angie Byron wrote:
>> At DrupalCon, a few of us had talked about how handy it would be to have a
>> module that automatically generated "scaffolding" for modules, both to help
>> new developers as well as to speed up the process of creating custom
>> modules for Drupal veterans.
>>
>> As a result of a major bout of insomnia, I am pleased to announce that
>> Module Builder Module 1.0 has been committed to CVS, and even pretty much
>> works! ;) You can check it out at:
>
>OK, I've not actually looked at it yet, so I can't comment on how 
>good/late-night the code is, but my knee-jerk reaction is that I don't like 
>code generation in the first place.  If the code is sufficiently boilerplate 
>that it can be auto-generated, then it's sufficiently boilerplate that it 
>should be written as a single routine and called with paramters.  That's the 
>logic behind functions and variables. :-)
>
>As a for-instance:
>
>hook_load(), hook_insert(), and hook_update() are horribly redundant.  All 
>three do the same thing in almost any node.  They select/insert/delete fields 
>from a table, using almost the same code.  Sometimes there will be an extra 
>table to manipulate, but there's still almost always a basic node++ table.  
>And the fields have to be specified in all of them.  Ick!
>
>The solution, however, isn't to have something that auto-generates those 
>functions.  It's to let the module define the table and fields once and then 
>let node.module handle the basic S-I-D.  Save those hooks for stuff that's 
>actually interesting, and reduce the amount of code, too.  
>
>I'm thinking something like:
>
>nodename_fields() {
>   return array('nodenametable' => array('field1', 'field2', 'field3'));
>}
>
>That would also allow node_load() to return an "empty node" of the correct 
>type, which would help with E_ALL compliance.
>
>(Yes, this is something I've been thinking about for some time, but have been 
>holding back on actually trying to implement because I didn't want to 
>introduce a change of that size when we've been "almost ready to get 4.7 out 
>the door" since, uh, November.  Hi, Ber! <g>  I actually did something very 
>similar to this at work, so I know it can be done.)
>
>So yeah, code generation in general gets a -1 for me in favor of more powerful 
>and generalized polymorphic code.
>

This is the most idiotic post I have read on this list so far. It starts with
"I've not actually looked at it yet"... Well, if you haven't looked at it, why
do you comment on it ? Do we care if you like code generation or not ? Do we
care if you like "powerful and generalized polymorphic code" ? That's not the
topic I think. This module is about building a module skeleton to make
developers job easier.

How do you think PHP extensions are written ? People use ext_skel or pecl
CodeGen and it saves them a lot of time and makes it more fun to hack something
fast. That's one thing that largely contributed to PHP success.

I am personally very thankful to the people who wrote Module_builder and will
start to use it straight away even if it's not "powerful and generalized
polymorphic code" :p



-- 
Bertrand Mansion
http://www.mamasam.com      - creative internet solutions
http://golgote.freeflux.net - blog