Gabe said: > 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.
yeah, i really don't want to do this every time either. > 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? first of all, session scope is just as safe as request. the only scope where thread-safety is a reasonable concern at all is application. second, the *very* least you can do is put the DateTool(Locale) constructor back (and working correctly of course). there is absolutely nothing unsafe about that when used as an application tool. that would at least allow me to easily extend it to make a DateTool of my own that can be easily used as a session or request tool. you went too far in your eagerness to make it thread-safe as an application tool. third, i don't appreciate you changing the target scope of tool i submitted without discussing it with me. i use the tools i submit in my classes and/or templates. you make it difficult to switch from my local versions when you make so many changes to the API. yes, i know and expect that things i submit will change, but when you change them that much i think it's at least common courtesy to discuss it with me first. and just for the record, it would have been just as easy for you to extend my version to be thread-safe in application scope, as it will be for me to extend your version (with the change i'm asking of course) to work well as request or session scope. > 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. not quite true, your trade-off entails one additional parameter for *all* of the methods in ParameterParser. as well as one more parameter for all DateTool methods that i want to be locale sensitive (as one would likely want from a request or session scoped DateTool). furthermore, i only use ParameterParser in request and session situations. so why would i want to make it so unfriendly to use in those situations? you claim to have helped by eliminating a "need", but it was not a "need" for such behaviour that prompted the original design but instead a desire for it! as such, i find the API of your version to quite unelegant and annoying. i will never agree that avoiding the instantiation of one measly object per request (particularly one as lightweight as my ParameterParser) is worth using (IMO) ugly and unweildy code. your fears about performance here are quite unreasonable. what you have done is added a trivial improvement in performance at the cost of a great deal of flexibility (in DateTool) and ease-of-use (in both classes). > 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. arghh!! how can you not see the case for that!!!?!!!??! i have spelled it out for you time and again!!! please read this ****i want a DateTool that can be easily used (or at least easily extended) to work reasonably in either application, session, or request scope!!!**** what is so hard for you to understand about that? if you'd like other cases, how about pretty much any tool that relies heavily on localization?! sorry if i seem a little exasperated about this, but if i'm do then it's probably because i am! this is not a non-issue or unrealistic case! this is a very simple, specific, and real case that i must have repeated to you about ten times by now!! and i'm not feeling very patient today! sorry. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
