cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: JXTemplateGenerator
Date Sat, 11 Dec 2004 10:36:29 GMT
Bertrand Delacretaz wrote:
> Le 11 déc. 04, à 00:57, Christopher Oliver a écrit :

>> ..."General consensus" has turned out to be incorrect on many 
>> occasions.

I guess many of us have seeked comfort in that idea, when not geting 
things our way. But while it might be a relevant idea for describing 
science development, the notion of being "correct" is not particulary 
usefull for discussing software development. In software devekopment it 
is much more important to create so much interest in ones ideas that 
people invest the energy in them, that makes them _become_ right. Is 
Unix and Widows NT the _correct_ operating systems?

Like it or not, striving for concensus is an important part of how the 
Cocoon community works. If it is efficient or not must be evaluated from 
the well being of the community and the quality of what we deliver.

>> What I see is that some people, such as Stefano, are 
>> looking to build a better templating system while others are 
>> contemplating what appears to be pointless refactoring...
> If the only goal is for these people to become more comfortable with the 
> code by refactoring, and especially if they're creating new tests along 
> the way it I'm happy. But I understand the refactoring can seem 
> pointless to you as you know this code much better.

For successfull code the time invested in writing the first version of 
it, is often a quite small fraction of all the developer time invested 
in the piexe of code during the life time of the project. And in the 
further development of a piece of code, reading and understanding the 
code often takes much longer time than adding the few lines of code that 
corrects the bug or add the new feature.

As a consequence, the efficiency of a piece of code cannot only be 
evaluated in terms of how well it does its work, but it must also be 
evaluated in how efficient it _communicates_ what it does to the ones 
that are reading it. And the communication style of JXTG is IMO entirely 
consistent with the email communication style of its author ;)

So if we succeed in making JXTG easier to digest for the Cocoon 
developer community and nothing more, it is still far from pointless, as 
it will going to save a lot of developer time in the future.

Now, my motivation for being involved in refactoring of JXTG, is to get 
it in such shape that I feel comfortable in using it as base for 
developing some new ideas on. Some of these new ideas has been discussed 
on the list and some are RTs that I don't have discussed yet.

>>> ...Any 3000-lines java source file *is* scary in my book, detailed 
>>> analysis would probably show that you code is indeed well structured, 
>>> but looking at it as it is now is scary for many people, myself 
>>> included.
>> OK, but the size of the source file has no effect on the behavior of 
>> the classes it contains. If someone wants to convert inner to external 
>> classes it is a trivial and mindless exercise.  In fact, I would 
>> hardly call it refactoring...
> Point taken, it's more like restructuring (damn, is there a function key 
> in IDEA to do this? ;-)
> The important thing for me is not really how the code looks though, but 
> how the people who are taking charge of it perceive it.

What have been done this far is just a first step, don't worry less 
mechanical things will be done. And while the size of a file doesn't 
affect its behavior, it might effect how well it communucates its behaviour.

>> ...  On the other hand the issues that Stefano raised bring up real 
>> problems that are not addressed by JXTG at all (nor any of the 
>> suggested alternatives)...
> Ok - there's probably more to do, but in the meantime JXTG is an 
> important component of Cocoon, so whatever big or small work people do 
> to improve it must be encouraged.
>> ...It's not personal, Bertrand. If someone does good work or makes a 
>> valid point I will give them proper respect. If not, well, I'm not 
>> teaching grade school and it's not my job to sugar coat it.

It might not be your job to sugar coat things, but you take the risk of 
focusing your audience energy and the response you get into other areas 
than the technical discussion, by not doing an effort in that direction.


View raw message