Class methods are Ruby's useEffect

As an aside, if you need to play with datetime objects in Ruby, you almost certainly want to be using the Time library instead of the DateTime library, even though one of them sounds like it fits better.

At the top of the DateTime docs [1]:

> DateTime class is considered deprecated. Use Time class.

The same doc explains when you should use DateTime by using an anecdote about William Shakespeare and Miguel de Cervantes dying on the same day - except they didn't because England and Italy used different calendars at the time. [2]

DateTime is great at dealing with historical pre-1970 dates, otherwise just use Time.

[1]: https://docs.ruby-lang.org/en/3.3/DateTime.html [2]: https://docs.ruby-lang.org/en/3.3/DateTime.html#class-DateTi...

I find it very odd to compare with useEffect. There's a whole bunch of things you can do in code that you could do another way, or might not be advisable for particular circumstances. And that's just about the only thing linking useEffect, a function call in React for component lifecycle, with class methods. I don't think it's a good idea to think about these two things in the same way.

The post says "Most of our Ruby code reads like English, but that’s not the case when we combine multiple DateTimeFns class methods", and to illustrate this, gives the following agreeably ugly example:

  DateTimeFns.add_minutes(DateTimeFns.add_hours(DateTime.current, 1), 1)

Sure thing, but the syntax can be improved without restorting to refactor into instance methods:

  DateTime.current.then {
   DateTimeFns.add_hours(_1, 1)
  }.then {
    DateTimeFns.add_minutes(_1, 1)
  }

As an outsider to the Ruby-World but someone who has been burnt enough times by instances unexpectedly mutating themselves, I wonder: is it still a best practice in Ruby to mutate instances when computing values? Does Ruby somehow avoid the problems that you would encounter when doing this in JS/Java/C#?

A bit of a stretch to compare them to each other.