[Zope3-dev] Re: Grok sprint 2 reports

[Martijn Faassen]

Max M wrote:
> Martin Aspeli skrev:
>>
>> If you're talking about ArchGenXML, which generates AT code from UML, 
>> it's
>> not too bad. The code it generates is pretty clean, and if you decide to
>> abandon code generation, there's a minimum of cruft (mostly a few comment
>> blocks) that you can remove if you wish.
> 
> Yes. I was unclear. Sorry. I meant AGX.
> 
> I use it for getting a project skeleton up and running quickly from 
> simple UML.
> 
> Something similar for Zope3 would be with me. Where the interfaces, 
> classes, zcml and views would be generated from UML.
>  
> But I will try out Grok, and see how the shoe fits before rambling on.

Code generation is dangerous if that code is going to be seen and edited 
by humans afterwards.

This danger is enhanced if that code generation has to happen more than 
one time for the same code base.

A code generator can write repetitive cruft for you. Unfortunately if 
generated code is expected to be edited by humans, this means you have 
to live with the cruft. That sucks.

This is especially bad if the code generation run happens more than 
once. If not, you can modify and get rid of the generated cruft, but if 
the generation run needs to happen again in the future, this is not 
possible.

Code generation is fine if humans never see it - a compiler generates 
code, for instance.

Setting up project infrastructure once with code generation isn't so 
dangerous. I would still like to examine whether the amount of files 
that a project needs cannot be reduced further in that case. There is a 
minor danger in the sense that code generation might make people less 
likely to remove cruft and just generate it instead. We should be 
careful that cruft doesn't grow too big, as people will inevitably have 
to edit it then.

Grok only does this simple code generation for project setup: grokproject.

The Grok project at present does not do anything else with code 
generation, and I think we should avoid this in the core project at 
present. Grok aims to reduce repetition quite aggressively, and it'd be 
much easier to accept such repetition if we had a code generator. I 
think that would be wrong, as in the end, for most projects, people will 
have to work with that Python code. In addition, we of course aim to 
support fully the use case of development *without* a code generator.

While AGX-style code generation is one way to make things easier for 
people, I'd want such a code generator to produce extremely trivial Grok 
code. The main reason to use something like AGX should be because:

* a UML style UI works better for some people

* there's simply a *lot* of models to work with and the UI can help here.

Not all complicated development projects have these requirements though.

Regards,

Martijn