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.
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.
"Class methods and useEffect are both things you could do another way or might not be advisable for particular circumstances" isn't a title that rolls off the tongue quite as nicely. ;-)
When I see useEffect, a little alarm goes off in my head telling me that it's worth exploring alternatives. I was hoping to give folks that same instinct for class methods. Didn't intend to imply that they performed similar functions, sorry if that's how you received it!
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:
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#?
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...
Wow, TIL! Thanks for sharing.
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.
"Class methods and useEffect are both things you could do another way or might not be advisable for particular circumstances" isn't a title that rolls off the tongue quite as nicely. ;-)
When I see useEffect, a little alarm goes off in my head telling me that it's worth exploring alternatives. I was hoping to give folks that same instinct for class methods. Didn't intend to imply that they performed similar functions, sorry if that's how you received it!
I see class methods as just methods on a singleton in ruby.
Of course calling constants directly means dependency, that's different.
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:
Sure thing, but the syntax can be improved without restorting to refactor into instance methods: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.