Gabe said: > Nathan, > my motivation was to make the tools thread-safe and thereby allowing > the reuse of the same instance for the entire runtime. The additional > method parameter for some of the methods seemed to be a reasonable > trade-off to me.
no, i think DateTool worked fine as an application scope tool as it was. sorry, but i don't see how your changes added anything. all they seem to do is make it much more difficult to use it as a session or request tool. if you are that concerned about it being thread-safe as an application tool, the only thing you needed to do was to remove the setLocale method. DateTool has no other mutators and no static members. i would much prefer, however, to leave the method so that those who wish to use the tool as a request or session tool may take advantage of it. if you're really afraid template designers will misuse the method, then do no more than make it protected to hide it from velocity introspection while still giving developers a chance at getting at it. at the very least, give me back the constructor that takes a locale parameter; there is nothing un-thread-safe about that. as for my ParameterParser, yes, it would not work correctly as an application scope tool, but seeing as the entire point of the class is to parse request parameters, i it is very poor style to use it in a global/application scope fashion! i completely disagree that what you have done there is a reasonable trade-off. :-/ sorry, but i never use nor intend to use ParameterParser as anything but request scope (either in templates or in initialization methods of other tools), and your changes make such usage quite annoying. i think you'll find most people will be unhappy with it. if you really need a static version so badly, make it a separate class. > Since we are discussing this in the context of auto-loading context > tools, performance is a real concern of mine. Every context tool class > that is not thread-safe must be instantantiated on every template > request. We are talking about hundreds of instances a second. what?! i highly doubt the instantiation of even a thousand instances a second of an object with so lightweight of a constructor would make an appreciable difference in any sane application/server setup. i think your fears of poor performance are unfounded. > I agree that your versions of the tools are a little more user- > friendly. I would use them in a non-auto-loading environment. Maybe > we should keep them in the library with a note that they are more > user-friendly but not thread-safe. -1 Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
