Issue #21264 has been updated by jeremyevans0 (Jeremy Evans). zverok (Victor Shepelev) wrote in #note-5:
I think an important question is whether the simplified Date should be ::Date, or something like ::Time::Date. One issue with making the simplified version ::Date is it opens up backwards compatibility issues for code that uses features removed in the simplification.
I am afraid that `::Time::Date` approach is mostly doomed. Assuming you have many instances of `Date` usage in the codebase (including some not-so-obvious ones, like `const_get` and deserialization), and the new Ruby version says there is this change, and you have two options: 1. `require 'date'` (the bundled "old Date") and everything works 2. replace everything with `::Time::Date`
People will inevitably mostly choose option 1.
For code that would be compatible with both simplified Date and stdlib Date, it would be possible to use the new `Date` by default easily: `Date = ::Time::Date`. For applications using Date, this could be done at top level. For most libraries that use date, this could be done inside the library's main module. So it is fairly easy to opt-in without forcing `s/Date/Time::Date/g`.
OTOH, the whole point of simplification is "almost nobody uses some parts of Date, so it is not reasonable to keep them in core/maintain".
So, if the new simplified class would be just `::Date`, some _very small_ amount of code will break (if it is not so, the Date shouldn't be simplified).
I agree that percentage-wise, I expect few applications/libraries would break. The question is what happens if you do have code that breaks. How do you fix it? I think we have to have an answer to this. I suppose one option is to rename stdlib `Date` from `::Date` to something else, so that only users that require non-simplified features need to modify their code.
For this case, I'd say 1. We might consider a bundled `date` library to extend the core (new) `Date` class with missing functionality (like stdlib `time` does)...
I considered this, and it would be great if it were possible. However, I'm not sure it is. Stdlib `time` is quite different in nature than what you are proposing, it only adds some class methods and a few conversion-to-string methods, nothing that requires additional storage.
2. And only if it turns out to be definitely impossible (due to incompatible internal representation), some new name might be introduced.
This was the reason I suggested a new name. If we simplify `Date`'s internal representation, it likely does not contain enough information for stdlib Date to work correctly in all cases. ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-112718 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- Note: This is not for Ruby 3.5. `Date` and `DateTime` has no primary maintainer in 10+ years. I would like to deprecate `date` via bundled gems for reducing our maintenance time especially @nobu. But `Time.prase` and `Time.strptime` are widely used now. How do we deprecate `date` library? 1. Migrate `Date._strptime`, `Date.strptime` and `Date._parse` to `Time`. The current `Date` is migrated as bundled gems. 2. Migrate `Date` to the bundled gems. `Time.parse` and `Time.strptime` warns if `date` is not found. 3. Keep the current situation 4. ... Does anyone have another idea? -- https://bugs.ruby-lang.org/