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
