Re: [Rails-core] To Patch or Not To Patch

2016-03-14 Thread queennina2016


On Friday, February 6, 2015 at 6:01:48 AM UTC+3, Matt jones wrote:
>
>
> On Feb 5, 2015, at 8:35 AM, Magne  wrote:
>
> I'd find it extremely useful. The current implementation sucks, for 
> various reasons.
>
> Actually, what you expect when you use *distance_of_time_in_words*, and 
> what arguably should be the default in rails, is for it to *output 
> precisely what you input*.
> The method is not called *rounded_distance_of_time_in_words*, after all.
>
> What you would expect:
>
> helper.distance_of_time_in_words(1.hour) => "1 hour"  not "about 1 
> hour" which it currently does.
> helper.distance_of_time_in_words(1.hour+ 15.minutes) =>   "1 hour and 15 
> minutes" or "one hour and a quarter."  and not "*about 1 hour*" which 
> it currently does.
>
> *Fancy rounding of hours and days should be something extra*, for the 
> people that need that. 
>
>
> Which, presumably, would be *everybody* who is using this helper now.
>
> For everyone else, there should be *sane defaults*, namely* a convention 
> that doesn't violate expectation*.
> You shouldn't have to monkey-patch the app, or use an extra gem, to get 
> the sane defaults.
>
>
> You brought a 5+-year-old thread back to life to insist that the current 
> behavior is not “sane”. [citation needed]
>  
>
> Currently, this is how fancy it has become:
>
> helper.distance_of_time_in_words(41.hours+ 59.minutes+29.seconds) =>* "1 
> day"*  eh.. WTF?  Since when did 1 day become 42 hours and not 
> 24? Even according to the rounding principles used, this doesn't make much 
> sense.
>
> Or these intervals:
>
> 1 yr <-> 1 yr, 3 months   
> # => about 1 year
> 1 yr, 3 months <-> 1 yr, 9 months 
> # => over 1 year
>
> Who on earth would be able to deduce from the output that 1 year and 3 
> months is "about one year", and not "over 1 year"?
>
> See all the fancy roundings here 
> 
>  in 
> the docs, and see if you don't agree with me.
>
> Having the expected precision is especially important when using this in 
> email communication towards users, or for communicating deadlines.
> *Precision doesn't hurt, apart from being a bit UX unfriendly at times. On 
> the other hand, imprecision and fancy roundings can be very damaging.*
>
> *I vote that the relevant parts of the dotiw gem be made a part of core 
> rails, since the default behavior should be intuitive and straightforward. *
>
>
> Make a PR then. Nobody has done it in the last 5 years, so I’m unconvinced 
> it is a thing anyone wants.
>
>
> ---
> *If you really find the fancy roundings useful*, leave it in rails, but 
> rename it to *rounded_distance_of_time_in_words*, fix the bugs, 
> and update it to support atleast half-hours, half-days and so on. Like this
> *:*
>
>
> I dunno who “you” is in the sentence above. If it bugs you this much, 
> again, submit a PR for discussion. You’ll need to explain why you want to 
> make a breaking change in every app that uses a function that hasn’t 
> changed in years, and you’ll need to provide a patch to deprecate the old 
> names in the next 4.x series release.
>
> —Matt Jones
>
>
> helper.distance_of_time_in_words(1.hour+ 29.minutes) =>   "one and a half 
> hour" or "one hour and a half."  and not "about 1 hour" which it 
> currently gives
>
> There is already established a precedence for including halves. It 
> currently supports half-minutes:
>
> helper.distance_of_time_in_words(0, 39.seconds, include_seconds: true) => 
> "half a minute"
> ---
>
> cheers,
>
> Magne Gåsland
>
> fredag 7. august 2009 07.44.11 UTC+2 skrev Ryan Bigg følgende:
>>
>> Recently a lot of people I've spoken with have expressed that 
>> distance_of_time_in_words sucks for accuracy, providing values such as 
>> "about 2 years" where "2 years, 5 months, 3 days, 4 hours, 6 minutes and 42 
>> seconds" is "more appropriate". To fix this, I've written a plugin: 
>> http://github.com/radar/dotiw. I'm thinking that this should be in Rails 
>> core as it is a vast improvement over what currently exists, but I don't 
>> want to put the effort into a patch that's just going to be rejected, as 
>> per usual.
>>
>> Who else would find this useful?
>>
>> -- 
>> Ryan Bigg
>>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-co...@googlegroups.com .
> To post to this group, send email to rubyonra...@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>
>
I think this thing is difficult to implement given the fact that months and 
years/leap-years lack symmetry. Implementing it would take lines and lines 
and lines of code and some 

Re: [Rails-core] To Patch or Not To Patch

2015-02-05 Thread Matt Jones

On Feb 5, 2015, at 8:35 AM, Magne magn...@gmail.com wrote:

 I'd find it extremely useful. The current implementation sucks, for various 
 reasons.
 
 Actually, what you expect when you use distance_of_time_in_words, and what 
 arguably should be the default in rails, is for it to output precisely what 
 you input.
 The method is not called rounded_distance_of_time_in_words, after all.
 
 What you would expect:
 
 helper.distance_of_time_in_words(1.hour) = 1 hour  not about 1 
 hour which it currently does.
 helper.distance_of_time_in_words(1.hour+ 15.minutes) =   1 hour and 15 
 minutes or one hour and a quarter.  and not about 1 hour which it 
 currently does.
 
 Fancy rounding of hours and days should be something extra, for the people 
 that need that. 

Which, presumably, would be *everybody* who is using this helper now.

 For everyone else, there should be sane defaults, namely a convention that 
 doesn't violate expectation.
 You shouldn't have to monkey-patch the app, or use an extra gem, to get the 
 sane defaults.

You brought a 5+-year-old thread back to life to insist that the current 
behavior is not “sane”. [citation needed]
 
 Currently, this is how fancy it has become:
 
 helper.distance_of_time_in_words(41.hours+ 59.minutes+29.seconds) = 1 day  
 eh.. WTF?  Since when did 1 day become 42 hours and not 24? Even 
 according to the rounding principles used, this doesn't make much sense.
 
 Or these intervals:
 
 1 yr - 1 yr, 3 months   # 
 = about 1 year
 1 yr, 3 months - 1 yr, 9 months # 
 = over 1 year
 
 Who on earth would be able to deduce from the output that 1 year and 3 months 
 is about one year, and not over 1 year?
 
 See all the fancy roundings here in the docs, and see if you don't agree with 
 me.
 
 Having the expected precision is especially important when using this in 
 email communication towards users, or for communicating deadlines.
 Precision doesn't hurt, apart from being a bit UX unfriendly at times. On the 
 other hand, imprecision and fancy roundings can be very damaging.
 
 I vote that the relevant parts of the dotiw gem be made a part of core rails, 
 since the default behavior should be intuitive and straightforward. 

Make a PR then. Nobody has done it in the last 5 years, so I’m unconvinced it 
is a thing anyone wants.


 ---
 If you really find the fancy roundings useful, leave it in rails, but rename 
 it to rounded_distance_of_time_in_words, fix the bugs, 
 and update it to support atleast half-hours, half-days and so on. Like this:
 

I dunno who “you” is in the sentence above. If it bugs you this much, again, 
submit a PR for discussion. You’ll need to explain why you want to make a 
breaking change in every app that uses a function that hasn’t changed in years, 
and you’ll need to provide a patch to deprecate the old names in the next 4.x 
series release.

—Matt Jones


 helper.distance_of_time_in_words(1.hour+ 29.minutes) =   one and a half 
 hour or one hour and a half.  and not about 1 hour which it 
 currently gives
 
 There is already established a precedence for including halves. It currently 
 supports half-minutes:
 helper.distance_of_time_in_words(0, 39.seconds, include_seconds: true) = 
 half a minute
 
 ---
 
 cheers,
 
 Magne Gåsland
 
 fredag 7. august 2009 07.44.11 UTC+2 skrev Ryan Bigg følgende:
 Recently a lot of people I've spoken with have expressed that 
 distance_of_time_in_words sucks for accuracy, providing values such as about 
 2 years where 2 years, 5 months, 3 days, 4 hours, 6 minutes and 42 seconds 
 is more appropriate. To fix this, I've written a plugin: 
 http://github.com/radar/dotiw. I'm thinking that this should be in Rails core 
 as it is a vast improvement over what currently exists, but I don't want to 
 put the effort into a patch that's just going to be rejected, as per usual.
 
 Who else would find this useful?
 
 -- 
 Ryan Bigg
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Ruby on Rails: Core group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to rubyonrails-core+unsubscr...@googlegroups.com.
 To post to this group, send email to rubyonrails-core@googlegroups.com.
 Visit this group at http://groups.google.com/group/rubyonrails-core.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups Ruby 
on Rails: Core group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail