JAZ- [Fwd: Re: svn commit: r586582 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilDateTime.java]

[Adrian Crum]

Tim Ruppert wrote:
> As an alternative to changing this Adrian, maybe you could just put some
> javadoc on the method that explains why someone might NOT want to use
> it. Then you'd get the best of both worlds - both the documentation AND
> the help.

I did better than that - I deprecated it:

https://issues.apache.org/jira/browse/OFBIZ-1361

The clients of Hotwax Media would be better served if its programmers spent more time writing well
crafted code, and less time defending inferior code.

-Adrian

[Jacopo Cappellato]

Please,

we are all working together to a great, exciting and ambitious project:
do you all think it is possible to use a positive, non aggressive, calm
attitude, *especially* when we are in disagreement on something?

Jacopo

Adrian Crum wrote:

> Tim Ruppert wrote:
>> As an alternative to changing this Adrian, maybe you could just put
>> some javadoc on the method that explains why someone might NOT want to
>> use it. Then you'd get the best of both worlds - both the
>> documentation AND the help.
>
> I did better than that - I deprecated it:
>
> https://issues.apache.org/jira/browse/OFBIZ-1361
>
> The clients of Hotwax Media would be better served if its programmers
> spent more time writing well crafted code, and less time defending
> inferior code.
>
> -Adrian
>

[Adrian Crum]

Jacopo Cappellato wrote:
> 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.

If Andrew provided the code fragment that prompted him to add this method, then I would be more than
happy to show him a better way to code it.

The Workeffort and Asset Maintenance calendars are two good examples of how to properly code
date/time calculations. Look for day.bsh, week.bsh, month.bsh, and the
getWorkEffortEventsByPeriod(...) method in WorkEffortServices.java.

> 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.

It's not a backward compatibility issue. Andrew's commit adds a method that's similar to one I
created a few months ago. He's not restoring something that was taken away.

-Adrian

[Tim Ruppert]

+1 to keeping the 'tude in your pants.

On Oct 26, 2007, at 8:45 AM, Jacopo Cappellato wrote:

Please,

we are all working together to a great, exciting and ambitious project:

do you all think it is possible to use a positive, non aggressive, calm attitude, *especially* when we are in disagreement on something?

Jacopo

Adrian Crum wrote:

Tim Ruppert wrote:

As an alternative to changing this Adrian, maybe you could just put some javadoc on the method that explains why someone might NOT want to use it. Then you'd get the best of both worlds - both the documentation AND the help.

I did better than that - I deprecated it:

https://issues.apache.org/jira/browse/OFBIZ-1361

The clients of Hotwax Media would be better served if its programmers spent more time writing well crafted code, and less time defending inferior code.

-Adrian

[Adam Heath-2]

Tim Ruppert wrote:
> +1 to keeping the 'tude in your pants.

badumpbumpchiz!

[David E Jones]

I disagree with leaning on deprecation because deprecation means "do  
not use", "convert all code that uses to use this other thing", and  
"this is slated for removal in some future release".

I don't think that would be accurate here...

-David


On Oct 26, 2007, at 3:03 AM, 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" <[hidden email]>
> À : <[hidden email]>
> 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
>>
>>
>

[David E Jones]

On Oct 26, 2007, at 8:37 AM, Adrian Crum wrote:

> Tim Ruppert wrote:
>> As an alternative to changing this Adrian, maybe you could just  
>> put some javadoc on the method that explains why someone might NOT  
>> want to use it. Then you'd get the best of both worlds - both the  
>> documentation AND the help.
>
> I did better than that - I deprecated it:
>
> https://issues.apache.org/jira/browse/OFBIZ-1361
>
> The clients of Hotwax Media would be better served if its  
> programmers spent more time writing well crafted code, and less  
> time defending inferior code.

Aside from the way this is phrased, the problem I have with this is  
that it's a dangerous notion.

Around 90% of what is in OFBiz is there because a client needed it.

That is THE BEST test we have for whether something is needed/wanted  
in the real world or not. Everything else is just speculative. Not  
that clients always have the best of ideas (it's all of our job to  
help with that), but this is the best "litmus test" (if you will) for  
what makes sense in the real world, which is after all what we're  
trying to provide for with this project.

-David

[Adrian Crum]

David E Jones wrote:

> On Oct 26, 2007, at 8:37 AM, Adrian Crum wrote:
>
>> Tim Ruppert wrote:
>>
>>> As an alternative to changing this Adrian, maybe you could just  put
>>> some javadoc on the method that explains why someone might NOT  want
>>> to use it. Then you'd get the best of both worlds - both the  
>>> documentation AND the help.
>>
>>
>> I did better than that - I deprecated it:
>>
>> https://issues.apache.org/jira/browse/OFBIZ-1361
>>
>> The clients of Hotwax Media would be better served if its  programmers
>> spent more time writing well crafted code, and less  time defending
>> inferior code.
>
>
> Aside from the way this is phrased, the problem I have with this is  
> that it's a dangerous notion.
>
> Around 90% of what is in OFBiz is there because a client needed it.
>
> That is THE BEST test we have for whether something is needed/wanted  in
> the real world or not. Everything else is just speculative. Not  that
> clients always have the best of ideas (it's all of our job to  help with
> that), but this is the best "litmus test" (if you will) for  what makes
> sense in the real world, which is after all what we're  trying to
> provide for with this project.
>
> -David

I used bad judgement in that final remark. I offer my apologies to the folks at Hotwax.

-Adrian

[Scott Gray]

I guess what I don't understand here is that if this new method could
possibly introduce bugs further down the track and the same result can
be achieved using existing methods, whats the big deal about using
those existing methods?

Scott

On 27/10/2007, Adrian Crum <[hidden email]> wrote:

> David E Jones wrote:
> > On Oct 26, 2007, at 8:37 AM, Adrian Crum wrote:
> >
> >> Tim Ruppert wrote:
> >>
> >>> As an alternative to changing this Adrian, maybe you could just  put
> >>> some javadoc on the method that explains why someone might NOT  want
> >>> to use it. Then you'd get the best of both worlds - both the
> >>> documentation AND the help.
> >>
> >>
> >> I did better than that - I deprecated it:
> >>
> >> https://issues.apache.org/jira/browse/OFBIZ-1361
> >>
> >> The clients of Hotwax Media would be better served if its  programmers
> >> spent more time writing well crafted code, and less  time defending
> >> inferior code.
> >
> >
> > Aside from the way this is phrased, the problem I have with this is
> > that it's a dangerous notion.
> >
> > Around 90% of what is in OFBiz is there because a client needed it.
> >
> > That is THE BEST test we have for whether something is needed/wanted  in
> > the real world or not. Everything else is just speculative. Not  that
> > clients always have the best of ideas (it's all of our job to  help with
> > that), but this is the best "litmus test" (if you will) for  what makes
> > sense in the real world, which is after all what we're  trying to
> > provide for with this project.
> >
> > -David
>
> I used bad judgement in that final remark. I offer my apologies to the folks at Hotwax.
>
> -Adrian
>
>
>

[Jacques Le Roux]

Then the ball is in Adrian's camp. And Adrian you should explain us your POV on this ML, and then maybe a vote ?

Jacques

De : "David E Jones" <[hidden email]>
I disagree with leaning on deprecation because deprecation means "do
not use", "convert all code that uses to use this other thing", and
"this is slated for removal in some future release".

I don't think that would be accurate here...

-David


On Oct 26, 2007, at 3:03 AM, 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" <[hidden email]>
> À : <[hidden email]>
> 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
>>
>>
>

[Tim Ruppert]

I guess the bigger question is what with all of the work needing to be done in the project - why does everyone seem to spend this much time on this issue?  My vote - just comment the method and move on.  Andrew's already given an explanation of why he put the method in there - good enough.  Adrian's already told his side of the story.  Great!   Now everyone's been heard - the method is not hurting anyone - comment it if you think it's a good idea - move on to other MUCH higher priority issues!

My two cents.

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Oct 27, 2007, at 9:19 AM, Jacques Le Roux wrote:

Then the ball is in Adrian's camp. And Adrian you should explain us your POV on this ML, and then maybe a vote ?

Jacques

De : "David E Jones" <[hidden email]>

I disagree with leaning on deprecation because deprecation means "do

not use", "convert all code that uses to use this other thing", and

"this is slated for removal in some future release".

I don't think that would be accurate here...

-David

On Oct 26, 2007, at 3:03 AM, 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" <[hidden email]>

À : <[hidden email]>

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

[Jacques Le Roux]

Hi Tim,
  De : Tim Ruppert
  À : [hidden email]
  Envoyé : samedi 27 octobre 2007 18:28
  Objet : Re: JAZ- [Fwd: Re: svn commit: r586582 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilDateTime.java]


  I guess the bigger question is what with all of the work needing to be done in the project - why does everyone seem to spend this much time on this issue?  
  I'm like that, it's one of my flaws : I can't resist to help someone (here we say "défendre la veuve et l'orphelin" in a mocking way)
  My vote - just comment the method
  Sounds wise
  and move on.  
  Not sure
  Andrew's already given an explanation of why he put the method in there - good enough.  
  Was clear yes, KISS way
  Adrian's already told his side of the story.  Great!   Now everyone's been heard - the method is not hurting anyone -
  Here I'm not sure Adrian think the same and I would like to well understand why
  comment it if you think it's a good idea
  I will not do anything, I just want to be sure to understand. I had no time this week-end to llok at the code, but nothing is blocking right now. I have all my time on this issue: no worries, no stress.
  - move on to other MUCH higher priority issues!
  Wooo... not so loud please ... (I don't fell like sitting and looking the train passing ;o)
  My two cents.
  Thanks for your comments.
  Cheers

  Jacques




  Cheers,
  Tim
  --
  Tim Ruppert
  HotWax Media
  http://www.hotwaxmedia.com


  o:801.649.6594
  f:801.649.6595




  On Oct 27, 2007, at 9:19 AM, Jacques Le Roux wrote:


    Then the ball is in Adrian's camp. And Adrian you should explain us your POV on this ML, and then maybe a vote ?


    Jacques


    De : "David E Jones" <[hidden email]>
    I disagree with leaning on deprecation because deprecation means "do
    not use", "convert all code that uses to use this other thing", and
    "this is slated for removal in some future release".


    I don't think that would be accurate here...


    -David




    On Oct 26, 2007, at 3:03 AM, 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" <[hidden email]>
      À : <[hidden email]>
      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