Make Time#utc and #localtime raise RuntimeError when the object is frozen#4657
Make Time#utc and #localtime raise RuntimeError when the object is frozen#4657headius merged 2 commits intojruby:masterfrom
Conversation
Time#utc and #localtime mutate the receiving instance even if it is frozen. In MRI this raises a RuntimeError.
|
Even though this makes JRuby consistent with MRI, and that this obviously is a bug, it's been in all versions of JRuby, as far as I can tell, so merging this could potentially break lots of libraries and applications. |
|
Generally, if we are doing behavior for which MRI errors, I'm not worried about fixing it. The truth is that all Ruby code is MRI code first and if they're not hitting the errors they're pretty much guaranteed not to have a problem with this change on JRuby. Of course there's plenty of JRuby-specific code out there but I doubt much of it is freezing and then calling mutative methods on Time objects. I'll review and merge if @enebo has no concerns. |
|
Yeah I agree fully with @headius. If something breaks then it is one off logic. Our strength is in good Ruby compatibility over the long run |
3 participants
This is a fix for #4655 that replicates the MRI behaviour of frozen
Timeobjects.It adds three tests to
spec/ruby/core/timethat cover the MRI behaviour of frozenTimeobjects – I've tried to match the style of the existing tests and copied tests for the same behaviour inArray. I hope it looks ok.The actual fix is very simple, in
#utcand #localtimeI've added a check that will throw aRuntimeError` when the instance is frozen.There are two additional public methods that mutate
Timeobjects, but they're not Ruby methods, and I'm unsure about whether or not they should throw errors:RubyTime#updateCal(DateTime)RubyTime#setDateTime(DateTime)They also seem to be duplicates of each other, an neither has been touched in 10 years.
Should they be changed to throw the same error, or how is frozen-ness handled when objects are changed from Java code?