Jeremias Maerki wrote: > I'm simply thinking that adding statics is a lot easier than > removing them again. I usually create non-static classes and > create singletons around them if necessary or convenient. > That's basically it. > > > One of the main purposes of > > FontServer was to share as much of the Font overhead as possible > > between documents in a heavy server environment, while > keeping a light > > footprint in the code. I actually tried to write it in a non-static > > way (with you in > > mind) in the beginning, but it just ended up being silly, > at least for > > the purposes that it is currently designed for. > > Of course, it makes sense to take the easy way to get quick results. > I'm just thinking about the long run.
I didn't do it for the quick results, but for the lighter, cleaner effect in the client application. Consider the pro-forma FontServer static method someMethod(). Right now, using such a method is simply FontServer.someMethod(). If I convert FontServer to a singleton, I see only two choices: 1. Create a static method getInstance() to return the singleton. To use someMethod(), I now need: FontServer.getInstance().someMethod(). 2. Cache the FontServer instance somewhere in the application client and pass it around. To use someMethod(), I now need: someObject.getFontServer().someMethod(). The only reason I can think of to use a Singleton instead of statics is that I might want to change my mind later & allow multiple instances. Since I have been unable to find even a potential use case for multiple instances that isn't covered by better client configuration, I didn't see the need for the extra complexity. However, I am not really opposed to using a singleton, and if it will make folks more comfortable, I'll reimplement it that way. BTW, I was under the impression that you disliked GoF singletons as much as statics. Are you OK with one here? > > Second, I *know* that, while in many ways HEAD is superior to the > > maintenance branch, there are many specific instances where the > > maintenance branch is superior to HEAD. I also know that > there is no > > convenient list of such items. I have to choose between the > two evils > > of 1) losing benefit(s) in the old code, and 2) losing > benefit(s) in > > the new code. Of the two, I prefer the latter. The user is > not going > > to be happy if I remove his wheels while installing the new, more > > powerful engine. Better IMO for us to upgrade the engine in > a manner > > that ensures that the wheels stay on. FOP is kind of into > the chasm thing, and FOray is definitely not. > > Right, but would you reconsider (in the long run) if we > worked towards seperately released components that could be > stabilized and shared between the different implementations? > All in the spirit of avoiding duplicate effort where this is possible? I understand you to be asking whether I want to create components that can be used by both the maintenance branch and HEAD. The answer is an emphatic YES. And I want all of the features that are in HEAD in those components. The only thing I meant to disagree with was the suggested approach of starting with HEAD as the baseline. IMO the correct approach is to start with the maintenance branch as the baseline and try to add in the code that has been added to HEAD as we are able to identify it and port it. Neither approach is ideal. If I understood the above correctly, then you and I may be in pretty close agreement on this whole approach. And, if you extend it a bit to other parts of FOP, you can see where I was headed with the isolation of FOTree, AreaTree, etc. It should be possible to factor everything out of FOP until you are left with layout, which could be / should be / would be the only difference between the maintenance branch and HEAD. Add in the concept of LayoutStrategy, and you have everything back in one unified line of development. > > and we can > > reconcile them. Ideally we want to get to the place where both > > branches are using the same code. I *think* that is pretty easy for > > Fonts and Graphics, but, as you say, probably not as easy > for PDF, and probably PostScript too. > > If it's possible for fonts then I'm sure it's possible for PDF and PS. My perception is that *not* many features have been added to fonts and graphics in HEAD, but that many have been for PDF and (possibly) PS. So my thinking is that if we missed a thing or two in fonts and graphics, we'll just deal with it as it comes. But with PDF and PS, we run the risk of losing some large chunks of utility if we don't have either 1) someone familiar with the changes guide the porting, or 2) someone go through some detailed diff work to try to ferret out the changes. I just want to make sure that my insistence in starting with the maintenance branch code instead of HEAD isn't perceived as underestimating the difficulty in that approach. It is ugly -- I just think it is less ugly than the alternatives. Victor Mote
