4 ms·

1.day? I confess to not being a Rubyist, but does that require monkeypatching the base int class? I don't see anything unreasonable about Pendulum's interface

by bjt 10y ago

1.day? I confess to not being a Rubyist, but does that require monkeypatching the base int class? I don't see anything unreasonable about Pendulum's interface. Let's let Python be Python and Ruby be Ruby.

Niksko 10y ago
No, don't think so. I think this is a native syntax construct in Ruby.
- teej 10y ago
  1.day is not a native Ruby concept, it is a method monkeypatched into the Numeric class by Rails' ActiveSupport. See http://api.rubyonrails.org/classes/Numeric.html#method-i-day http://api.rubyonrails.org/classes/Numeric.html#method-i-day and https://ruby-doc.org/core-2.2.0/Numeric.html https://ruby-doc.org/core-2.2.0/Numeric.html.
  - twblalock 10y ago
    I can see how people think it is native Ruby. Very few people use Ruby without Rails.
teej 10y ago
Well, for a long time, letting "Python be Python" required dealing with absolutely terrible time zone support. As an example, Python's strptime only got timezone support (in %z) in version 3.2 in 2011.
tedmiston 10y ago
Similar idea to Ruby's .times() method [0]. [0]: http://ruby-doc.org/core-1.9.3/Integer.html#method-i-times http://ruby-doc.org/core-1.9.3/Integer.html#method-i-times
dasil003 10y ago
I am a rubyist for over a decade now, and while I don't have a problem with the monkeypatching per se, I don't think anyone should be holding up ActiveSupport's time zone support as a paragon of good API design. Yes, on the surface it looks pretty nice, but because of the weird mix of different classes and extensions you get a frankenstein API that is a very leaky abstraction. I could dig up a raft of examples, but just off the top of my head... Date.today respects the global setting of Time.zone, but Date.yesterday always gives you the UTC date. The inconsistencies and permutations of Date, DateTime, Time, and TimeWithZone, combined with machine clock, Time.zone global, and UTC lead to so much confusion that the only way to ensure correctness is to declare a subset of the API which you always use, and reject everything else just so your team gets used to reasoning about it. Sorry for the rant, but I've spent many years as the only California developer for a time based in the UK, suffering the tyranny of developers who spend half their year blissfully living in UTC and unknowingly foisting off their dirty time zone bugs on me.

by bjt 10y ago

Niksko 10y ago

No, don't think so. I think this is a native syntax construct in Ruby.

teej 10y ago
1.day is not a native Ruby concept, it is a method monkeypatched into the Numeric class by Rails' ActiveSupport. See http://api.rubyonrails.org/classes/Numeric.html#method-i-day http://api.rubyonrails.org/classes/Numeric.html#method-i-day and https://ruby-doc.org/core-2.2.0/Numeric.html https://ruby-doc.org/core-2.2.0/Numeric.html.
- twblalock 10y ago
  I can see how people think it is native Ruby. Very few people use Ruby without Rails.

teej 10y ago

Well, for a long time, letting "Python be Python" required dealing with absolutely terrible time zone support. As an example, Python's strptime only got timezone support (in %z) in version 3.2 in 2011.

tedmiston 10y ago

Similar idea to Ruby's .times() method [0]. [0]: http://ruby-doc.org/core-1.9.3/Integer.html#method-i-times http://ruby-doc.org/core-1.9.3/Integer.html#method-i-times

dasil003 10y ago

I am a rubyist for over a decade now, and while I don't have a problem with the monkeypatching per se, I don't think anyone should be holding up ActiveSupport's time zone support as a paragon of good API design. Yes, on the surface it looks pretty nice, but because of the weird mix of different classes and extensions you get a frankenstein API that is a very leaky abstraction. I could dig up a raft of examples, but just off the top of my head... Date.today respects the global setting of Time.zone, but Date.yesterday always gives you the UTC date. The inconsistencies and permutations of Date, DateTime, Time, and TimeWithZone, combined with machine clock, Time.zone global, and UTC lead to so much confusion that the only way to ensure correctness is to declare a subset of the API which you always use, and reject everything else just so your team gets used to reasoning about it. Sorry for the rant, but I've spent many years as the only California developer for a time based in the UK, suffering the tyranny of developers who spend half their year blissfully living in UTC and unknowingly foisting off their dirty time zone bugs on me.