Yes good consensus Jacques
De : "Scott Gray" <[EMAIL PROTECTED]> Sounds smart to me Scott On 26/10/2007, Jacopo Cappellato <[EMAIL PROTECTED]> wrote: > > Sorry, > > I jump in very late in this thread, I'd like to express my point of view > even if I'm missing some of the details and I could be wrong. > > I guess that the issue that Andrew faced was related to external > components based on OFBiz: after the OFBiz upgrade they could not > compile because they were using the original datetime methods (not > timezone aware). > If this is true, then maybe Adrian could help by providing an example to > upgrade the old calls to the new ones (for bsh or for ftl etc...); I'm > sure he already did this somewhere, but it is not always easy to track > down where such information is. > In my opinion, adding the method for backward compatibility as Andrew > did it is acceptable too, but I would suggest to deprecate it (and put > an informative message in the deprecation worning to facilitate the > migration) or at least add a warning message in the log: again, Adrian > could help preparing these messages. > > Just my 2 cents, > > Jacopo > > > Jacques Le Roux wrote: > > And this were comments Adrian, Wickersheimer Jeremy and I put in this > issue > > > > =================================================== > > Adrian Crum - 21/oct./07 04:15 PM > > David, > > > > Thanks for your input. I don't understand what you're saying though. > > > > If those methods aren't deprecated, then developers will continue to use > them. This will lead to problems down the road with > > inconsistent data - users are going to encounter two different results > for the same date/time criteria. Are you saying inconsistent > > data is something we should allow? > > =================================================== > > > > =================================================== > > Wickersheimer Jeremy - 21/oct./07 07:06 PM > > David, i understand your point but marking the methods deprecated > doesn't remove them, so they can still be used. > > However they should not be used, as Adrian points out they do not use > the correct locale so there output will be inconsistent. > > Marking the deprecated is a good way to say that the code using them > should be migrated at, and it would also make the compiler > > throw out useful warnings. > > =================================================== > > > > =================================================== > > Jacques Le Roux - 21/oct./07 11:12 PM > > David, > > > > I agree with David and Jeremy. Deprecating and documenting it in code > seems a good idea in this case. There are better chances to be > > read than in the Best practices Guides (pragmatic POV) which does not > mean that this should not be documented at this higher level > > too. Is there something else we are missing ? > > =================================================== > > > > So I maybe misunderstood but if deprecating is the way here (you did not > say anything about that) why put in the framework a static > > method which, according to Adrian and his noon+24h exmaple, is a bad > practice ? > > Maybe Adrian is wrong about his example but he has done a lot of work > around this issue hence it's doubtful. > > > > Mainly to second Adrian who is really alone trying to explain his view. > > > > Jacques > > > > ----- Message d'origine ----- > > De : "David E Jones" <[EMAIL PROTECTED]> > > À : <[email protected]> > > Envoyé : vendredi 26 octobre 2007 02:28 > > Objet : Re: JAZ- [Fwd: Re: svn commit: r586582 - > /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilDateTime.java] > > > > > >> On Oct 25, 2007, at 5:16 PM, Adrian Crum wrote: > >> > >>> Andrew, > >>> > >>> I understand what the method does. The point I'm trying to make is > >>> this: It is not needed and it provides a way to introduce > >>> inconsistent data into the project. > >>> > >>> I understand the method solves a problem for a particular client, > >>> but it's not a good thing to include in the project. > >>> > >>> There is a discussion on Jira about this: > >>> > >>> https://issues.apache.org/jira/browse/OFBIZ-1361 > >> Yes, and Adrian you seem to have missed my point there, or maybe you > >> disagree with me? > >> > >> The framework is NOT around to force stuff. Here is what I wrote there: > >> > >> =================================================== > >> While I agree that this should be the best practice, there is a big > >> difference in the framework between what we "allow" and what we > >> "recommend". > >> > >> There is lots of stuff you _can_ do with the framework that is really > >> not a good idea, thought some might disagree. Things that we > >> recommend should be documented in the Best Practices Guide. Other > >> things we don't want to make more difficult, IMO, that this is > >> important because of the comment about disagreement above. There are > >> pretty much always good reasons why we do things the way we recommend > >> in the framework, but those recommendations have evolved over time > >> and will continue to evolve as well, and not allowing things we don't > >> recommend stifles this and limits opportunity to progress and improve. > >> > >> That is of course a generality, and there is a clear best practice > >> here that should be documented and it probably won't ever change, but > >> I'm still against forcing on a matter of principle. > >> =================================================== > >> > >> If you have an issue with that, let's discuss that directly, and if > >> necessary vote on it. That seems to be the difference of opinion, so > >> let's resolve it... now. > >> > >> -David > >> > >> > > >
