Nathan Bubna wrote: > 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.
Well, our disagreement is really over how much we value flexibility vs. usability vs. safety vs. performance of a tool. I am wondering what requirements we should apply for the tools that go into the library. We certainly can't have such a discussion back and forth for each tool that we add. My expectation was that simple tools like a date formatter should be thread-safe such that we can reuse instances. If the tool is not thread-safe, the only reasonable and safe scope is 'request' in my view. If something like a date formatter can't even be reused, what can? > 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. The point of my changes was to make it thread-safe such that you would never need to use it in session or request scope. The trade-off is one additional parameter for some of the methods. Based on your feedback, this seems a quite unreasonable trade-off. You repeately bring up that case where one tools would be used in different scopes. I just don't see the case for that. All tools that I can imaging have a scope fixed by their design. If there really is an exotic case where you need variable scopes, there are easy work-arounds. You can always place a tool into one of the scopes manually. My current feeling is that this scope thing is adressing an non-issue. Gabe -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
