Glen Mazza wrote: > I've bought it due to my work with the apps package and > removing AddLMVisitor, and how reducing the complexity > allowed many other changes in other areas that weren't > previously apparent to occur. I also think that many of your > later enhancements in properties wouldn't have become obvious > if you didn't first get us out of the XSLT-generated > properties classes. Even I was able to implement some > (minor) property-related API changes as a result of your work > in getting rid of the autogenerated code.
I know better than to take this bait, but ... 1. The XSLT-generated stuff is a separate issue. Not relevant here at all. 2. It has already been pointed out that, if the Visitor stuff was so terribly complex, there were other solutions that could be applied that didn't sacrifice modularity. Also, it was never intended as a long-term solution, but rather reflected the current state of the layout design, which, after modularization, would have (or could have) changed. 3. Things should be made as simple as they can be, and no simpler. More importantly, there are tradeoffs even within simplicity. Modularization is one aspect of simplicity. It is true that modularization requires the use of interfaces, which add some incremental complexity. But the benefits of having good interfaces and clean separation of concerns reduce complexity much more on a different axis. I have said before that I am glad that Xalan is a separate module from FOP -- that was good thinking. I'm glad that FOP doesn't have to compute disk sectors or lay out pixels on a page -- somebody was smart enough to abstract out operating systems and printer drivers instead. Now, some on this list persist in the "let's finish coding the project and then we'll stop and design it" line of argument. I have taken it as a settled issue that this is FOP's policy, hence FOray. I won't work on a project that takes that attitude. I unwittingly tried that for about 18 months, lost a year of my life and an incalculable amount of money in both real and opportunity costs. FOP lost a good (IMO) developer and managed to create for itself unnecessary and wasteful competition where none was really needed. What a waste. So here is a promising developer that shows up with an idea. It helps him get his work done, and seems to make for a cleaner design (I haven't looked at it closely, but I haven't heard anybody argue with this). You can tell him (like you did me) "we don't need no steeenking clean design." Or you can learn a lesson and try to start developing relationships with the kind of developers that you are going to need to finish this project. Makes no difference to me. But, please, if you choose the former, send that promising developer toward FOray -- I'm almost at the stage where I can drop in the new layout system there. We'll find a place for good design ideas there. Victor Mote
