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.
/Daniel
