Feature #21616
open
date ライブラリを deprecated させたい
Description
概要¶
date ライブラリが長期間メンテナンスされておらず、機能を time ライブラリに委譲して deprecated させたい
というお話が出ていると風の噂で耳にしましたが、どこまでを考えられているのかご意見をお聞きしたいです。
確認事項¶
Date._parse を time に移植したい¶
Time._parse なるものが実現できれば十分でしょうか？（それっぽく移植はしてみました。）
Date.strptime を time に移植したい¶
date_strptime.c をそのまま time に移植していいものでしょうか？
「time に移植するならついでにこんな感じだと嬉しい」といった要望があったりするのでしょうか？
deprecated させた場合の影響範囲¶
deprecated はかなりのインパクトであり、様々な gem やプロダクトに影響を及ぼすかと思います。
例えば「Ruby on Rails では誰に相談すべきか」など、どこまでを考慮すべきでしょうか？
Updated by nobu (Nobuyoshi Nakada) 22 days ago
jinroq (Jinroq SAITOH) wrote:
Date._parseを time に移植したい¶
Time._parseなるものが実現できれば十分でしょうか？（それっぽく移植はしてみました。）
むしろ、あまりにもheuristicすぎるTime.parseこそが廃止したい筆頭ですね。
また、実装面で言うとCとrubyをfuncallとblockで繰り返し行き来するというのも、少なくともVM化した1.9以降では有利とは言えません。
Date.strptimeを time に移植したい¶date_strptime.c をそのまま time に移植していいものでしょうか？
「time に移植するならついでにこんな感じだと嬉しい」といった要望があったりするのでしょうか？
しばらく前から考えているのが、基準になる時刻はどうせ必要なので、クラスメソッドではなくインスタンスメソッドのほうがいいのではということです。
こんな感じ。
basetime = Time.now
basetime.parse(time_string, format: ["%FT%T%Z", "%F %T %Z", "%+"])
ただ、可能なformatを全部渡すという形だと、省略を許すという記法がないと使いづらいかもという懸念はあります。
deprecated させた場合の影響範囲¶
deprecated はかなりのインパクトであり、様々な gem やプロダクトに影響を及ぼすかと思います。
例えば「Ruby on Rails では誰に相談すべきか」など、どこまでを考慮すべきでしょうか？
影響範囲などが読めないというのも、なかなか手が進まない理由にあります。
Updated by jinroq (Jinroq SAITOH) 19 days ago
nobu (Nobuyoshi Nakada) wrote in #note-1:
回答ありがとうございます。
jinroq (Jinroq SAITOH) wrote:
Date._parseを time に移植したい¶
Time._parseなるものが実現できれば十分でしょうか？（それっぽく移植はしてみました。）むしろ、あまりにもheuristicすぎる
Time.parseこそが廃止したい筆頭ですね。
また、実装面で言うとCとrubyをfuncallとblockで繰り返し行き来するというのも、少なくともVM化した1.9以降では有利とは言えません。
2011 年頃に書かれたコードをそのまま使っていますので時期的に 1.9.3 頃のものですね…。
（Time._parse を採用するかどうかは置いておいて）無理に C で書かずとも pure ruby で書き直した方が良かったりしますかね。
Date.strptimeを time に移植したい¶date_strptime.c をそのまま time に移植していいものでしょうか？
「time に移植するならついでにこんな感じだと嬉しい」といった要望があったりするのでしょうか？しばらく前から考えているのが、基準になる時刻はどうせ必要なので、クラスメソッドではなくインスタンスメソッドのほうがいいのではということです。
こんな感じ。basetime = Time.now basetime.parse(time_string, format: ["%FT%T%Z", "%F %T %Z", "%+"])ただ、可能な
formatを全部渡すという形だと、省略を許すという記法がないと使いづらいかもという懸念はあります。
参考になります。ありがとうございます。
deprecated させた場合の影響範囲¶
deprecated はかなりのインパクトであり、様々な gem やプロダクトに影響を及ぼすかと思います。
例えば「Ruby on Rails では誰に相談すべきか」など、どこまでを考慮すべきでしょうか？影響範囲などが読めないというのも、なかなか手が進まない理由にあります。
そうですよね…。
Updated by naruse (Yui NARUSE) 5 days ago
- Related to Feature #21264: Extract Date library from Ruby repo in the future added
Updated by naruse (Yui NARUSE) 5 days ago
jinroq (Jinroq SAITOH) wrote in #note-2:
nobu (Nobuyoshi Nakada) wrote in #note-1:
回答ありがとうございます。
jinroq (Jinroq SAITOH) wrote:
Date._parseを time に移植したい¶
Time._parseなるものが実現できれば十分でしょうか？（それっぽく移植はしてみました。）むしろ、あまりにもheuristicすぎる
Time.parseこそが廃止したい筆頭ですね。
また、実装面で言うとCとrubyをfuncallとblockで繰り返し行き来するというのも、少なくともVM化した1.9以降では有利とは言えません。2011 年頃に書かれたコードをそのまま使っていますので時期的に 1.9.3 頃のものですね…。
（Time._parse を採用するかどうかは置いておいて）無理に C で書かずとも pure ruby で書き直した方が良かったりしますかね。
実装をどうするかよりも、Time.parseがRubyに必要かという議論をするのがよいと思います。
今のままのものがそのまま欲しいかというとNoよりだと思います。
じゃあ全くいらないのかというと悩ましいところで、まずここでいう Time.parse とは何かから考える必要があって、
それはおそらく複数フォーマットに対応した日付パースメソッドでしょう。
なので、議論は
- 複数フォーマットに対応した日付パースメソッドは欲しいか？
- 欲しいならどのようなフォーマットに対応していてほしいか？ ISO 8601, RFC822, Cookie datetime(822の区切りが-のもの)など
Date.strptimeを time に移植したい¶date_strptime.c をそのまま time に移植していいものでしょうか？
「time に移植するならついでにこんな感じだと嬉しい」といった要望があったりするのでしょうか？しばらく前から考えているのが、基準になる時刻はどうせ必要なので、クラスメソッドではなくインスタンスメソッドのほうがいいのではということです。
こんな感じ。basetime = Time.now basetime.parse(time_string, format: ["%FT%T%Z", "%F %T %Z", "%+"])ただ、可能な
formatを全部渡すという形だと、省略を許すという記法がないと使いづらいかもという懸念はあります。参考になります。ありがとうございます。
すべてのコンポーネントがあるならbasetimeは必要ないので、インスタンスメソッドが適切なんですかねぇ
deprecated させた場合の影響範囲¶
deprecated はかなりのインパクトであり、様々な gem やプロダクトに影響を及ぼすかと思います。
例えば「Ruby on Rails では誰に相談すべきか」など、どこまでを考慮すべきでしょうか？影響範囲などが読めないというのも、なかなか手が進まない理由にあります。
そうですよね…。
関連チケットにつけていたリポジトリ分割など少しずつ使うコストを上げていくという手はあるかもしれませんね。