Feature #735: Date#inspect

• Status: Closed
• Assignee: -
• Target version: -

[rubikitch (rubikitch .)]

=begin
「inspectは人間に優しい文字列化」という観点から、Date#inspectの出力はふさわしくないと思います。
#<Date: 2008-11-10> やら #<DateTime 2008-11-10T05:22:03+09:00> のほうがわかりやすいです。

require 'date'
Date.today # => #<Date: 4909561/2,0,2299161>
Date.today.to_s # => "2008-11-10"
DateTime.now # => #<DateTime: 2120930221235025923/864000000000,3/8,2299161>
DateTime.now.to_s # => "2008-11-10T05:22:03+09:00"
=end

[tadf (tadayoshi funaba)]

=begin

「inspectは人間に優しい文字列化」という観点から、Date#inspectの出力はふさわしくないと思います。
#<Date: 2008-11-10> やら #<DateTime 2008-11-10T05:22:03+09:00> のほうがわかりやすいです。

「inspectは人間に優しい文字列化」というのは初めて聞きました。現状では本
質部分がすべて見えているので、それなりに気に入っていますが、現状のよう
な情報が大部分の人間に無用である、ということなら、inspect も to_s と同
じようにしてもいいかもしれません。

ただ、inspect というのは、smalltalk 由来じゃないかと思うのですが、その
考えかたからすれば、現状の inspect は外れてはいないように思います。デフォ
ルトの inspect の振舞いからもそう感じます。to_s と殆ど変らない情報を提
供することには疑問を感じます。

たとえば以下の、a と b は違うのですが、いくらか秒以下の桁を表示すること
にしてもその違いは判らないかもしれません。

a = DateTime.parse('2008-11-10T01:02:03.123456789')
b = DateTime.parse('2008-11-10T01:02:03.1234567891')

また、同じ日付のように見えても、グレゴリオ暦とユリウス暦では違うわけで
すが、そういうことも判りません。現状では、違いははっきりします。
inspect とはそういうものじゃないかという気がします。to_s したら同じよう
に見えた日付も違うものだった、という事が判ればデバッグに役立つと思いま
す。

ここで「俺の考える inspect」を述べ合ってもしょうがないので、そもそも
ruby の inspect はどうあるべきだったのか、まつもとさんに訊いてからどう
したらいいか考えたほうがいいでしょうか。

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:37056] Re: [Feature #735] Date#inspect"
on Mon, 10 Nov 2008 21:33:56 +0900, Tadayoshi Funaba [e-mail] writes:

|> 「inspectは人間に優しい文字列化」という観点から、Date#inspectの出力はふさわしくないと思います。
|> #<Date: 2008-11-10> やら #<DateTime 2008-11-10T05:22:03+09:00> のほうがわかりやすいです。
|
|「inspectは人間に優しい文字列化」というのは初めて聞きました。現状では本
|質部分がすべて見えているので、それなりに気に入っていますが、現状のよう
|な情報が大部分の人間に無用である、ということなら、inspect も to_s と同
|じようにしてもいいかもしれません。
|
|ただ、inspect というのは、smalltalk 由来じゃないかと思うのですが、その
|考えかたからすれば、現状の inspect は外れてはいないように思います。デフォ
|ルトの inspect の振舞いからもそう感じます。to_s と殆ど変らない情報を提
|供することには疑問を感じます。

私はSmalltalkerではないので、いただいて来たのはinspectという
名前だけです。で、inspectの目的は何かと言うと、pが表示に用い
ることから考えても、なんらかの理由でto_sの情報だけからオブジェ
クトの情報を読み取ることが難しい時に、より多くの(人間にとって
読みやすい/わかりやすい)情報をデバッグ向けに提供するというこ
とでしょう。ここにおいては誰もそれほどは相違していないと思い
ます。

|たとえば以下の、a と b は違うのですが、いくらか秒以下の桁を表示すること
|にしてもその違いは判らないかもしれません。
|
| a = DateTime.parse('2008-11-10T01:02:03.123456789')
| b = DateTime.parse('2008-11-10T01:02:03.1234567891')
|
|また、同じ日付のように見えても、グレゴリオ暦とユリウス暦では違うわけで
|すが、そういうことも判りません。現状では、違いははっきりします。
|inspect とはそういうものじゃないかという気がします。to_s したら同じよう
|に見えた日付も違うものだった、という事が判ればデバッグに役立つと思いま
|す。

ここで、ふなばさんのおっしゃることもよくわかるのですが、個人
的にはDate#inspectがto_sに近い書式であったらなあ、と思ったこ
とが一度ならずあります。確かにDate#inspectではすべての情報を
提供しているのですが、それが人間世界(？)でどのような意味を持
つかということが読み取りにくいからです。

私のように単に「ある日」を指すオブジェクトとして使うことの方
が圧倒的に多い人には現在のinspectの情報は「やさしい」とは言え
ませんね。pで出力させても何日なのかわからないからです。結局
to_sで表示し直すことになるという。でも、Dateそのもののデバッ
グには現在の方がうれしいでしょうね。

|ここで「俺の考える inspect」を述べ合ってもしょうがないので、そもそも
|ruby の inspect はどうあるべきだったのか、まつもとさんに訊いてからどう
|したらいいか考えたほうがいいでしょうか。

どこかに妥協点があるとよいのですが。ただ、私はinspectがto_s
と同様の「人間にわかりやすい日付(DateTimeの場合は時間も)」の
表現 も 含むことを期待します。

                             まつもと ゆきひろ /:|)

=end

[hiroshi (Hiroshi MORIYAMA)]

=begin
Yukihiro Matsumoto wrote:

どこかに妥協点があるとよいのですが。ただ、私はinspectがto_s
と同様の「人間にわかりやすい日付(DateTimeの場合は時間も)」の
表現 も 含むことを期待します。

デバッグモードのときだけ詳細な情報を返すというのはどうでしょうか。

例:

% ruby1.9 -rdate -e 'p Date.today'
2008-11-11

% ruby1.9 -rdate -e 'p Date.today' -d
#<Date: "2008-11-11", @ajd=4909563/2, @of=0, @sg=2299161>

% ruby1.9 -rdate -e 'p DateTime.now'
2008-11-11T06:24:32+09:00

% ruby1.9 -rdate -e 'p DateTime.now' -d
#<DateTime: "2008-11-11T06:24:32+09:00", @ajd=21209311227209169197/8640000000000, @of=3/8, @sg=2299161>

パッチ:

Index: lib/date.rb

--- lib/date.rb (revision 20171)
+++ lib/date.rb (working copy)
@@ -1469,8 +1469,15 @@
# Calculate a hash value for this date.
def hash() @ajd.hash end

• Return internal object state as a programmer-readable string.

• def inspect() format('#<%s: %s,%s,%s>', self.class, @ajd, @of, @sg) end

• If +$DEBUG+ is true, returns internal object state as a programmer-readable

• string. Otherwise the same as +to_s+.

• def inspect

• if $DEBUG

•  format('#<%s: %s @ajd=%s, @of=%s, @sg=%s, "%s">', to_s, self.class, @ajd, @of, @sg)
  

• else

•  to_s
  

• end

• end

  Return the date as a human-readable string.

=end

[tadf (tadayoshi funaba)]

=begin

どこかに妥協点があるとよいのですが。ただ、私はinspectがto_s
と同様の「人間にわかりやすい日付(DateTimeの場合は時間も)」の
表現 も 含むことを期待します。

長いですけど、

#<DateTime: 2008-11-11T00:00:00+00:00 (4909563/2,0,2299161)>

こんなんでもいいですか。

別ものとして Object#examine とかで smalltalk の inspect 相当の目的で

#<クラス名: to_s (インスタンス変数の内容)>

のような内容を返すものがあればそのほうがいいのかも。

=end

[rubikitch (rubikitch .)]

=begin
From: Tadayoshi Funaba [e-mail]
Subject: [ruby-dev:37059] Re: [Feature #735] Date#inspect
Date: Tue, 11 Nov 2008 06:59:30 +0900

どこかに妥協点があるとよいのですが。ただ、私はinspectがto_s
と同様の「人間にわかりやすい日付(DateTimeの場合は時間も)」の
表現 も 含むことを期待します。

長いですけど、

#<DateTime: 2008-11-11T00:00:00+00:00 (4909563/2,0,2299161)>

こんなんでもいいですか。

いいと思います。

--
rubikitch
Blog: http://d.hatena.ne.jp/rubikitch/
Site: http://www.rubyist.net/~rubikitch/

=end

[mame (Yusuke Endoh)]

=begin
遠藤です。

2008/11/10 5:23 rubikitch . [e-mail]:

「inspectは人間に優しい文字列化」という観点から、Date#inspectの出力はふさわしくないと思います。
#<Date: 2008-11-10> やら #<DateTime 2008-11-10T05:22:03+09:00> のほうがわかりやすいです。

最終的には yugui さんの判断によりますが、これは完全に仕様変更なので
1.9 系列には導入するべきでないと思います。
そして yugui さんはこれを許可すべきでないと私は思います。

すごく良い提案だと思うので、個人的にも残念ではありますが……。

String#inspect を String#dump のように使う人が減らないという話も
あるので、明示的に

• 組み込み・添付ライブラリ内の inspect はすべて未定義挙動である
  • デバッグ時にのみ「人間によみやすい文字列化」を行うことを期待
    してよい
  • 最終的にその挙動 (や戻り値) に依存したコードを書いてはならない
  • (そもそも未定義挙動なので言うまでもないが、挙動は常に変更されうる)

という仕様にしとけばよかったですねえ。

--
Yusuke ENDOH [e-mail]

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:37061] Re: [Feature #735] Date#inspect"
on Tue, 11 Nov 2008 12:21:13 +0900, "Yusuke ENDOH" [e-mail] writes:

|2008/11/10 5:23 rubikitch . [e-mail]:
|> 「inspectは人間に優しい文字列化」という観点から、Date#inspectの出力はふさわしくないと思います。
|> #<Date: 2008-11-10> やら #<DateTime 2008-11-10T05:22:03+09:00> のほうがわかりやすいです。
|
|最終的には yugui さんの判断によりますが、これは完全に仕様変更なので
|1.9 系列には導入するべきでないと思います。
|そして yugui さんはこれを許可すべきでないと私は思います。
|
|すごく良い提案だと思うので、個人的にも残念ではありますが……。

最初の方針通り、変更はtrunkに行われるべきです。そしてその変更
を1.9.1に取り込むかどうかの判断はYuguiさん(だけ)が行います。
Yuguiさんが迷われたなら、ここに相談されることもあるでしょうが。

|String#inspect を String#dump のように使う人が減らないという話も
|あるので、明示的に
|
| - 組み込み・添付ライブラリ内の inspect はすべて未定義挙動である
| - デバッグ時にのみ「人間によみやすい文字列化」を行うことを期待
| してよい
| - 最終的にその挙動 (や戻り値) に依存したコードを書いてはならない
| - (そもそも未定義挙動なので言うまでもないが、挙動は常に変更されうる)
|
|という仕様にしとけばよかったですねえ。

将来の「仕様」ではそうなることを視野に入れましょう。

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:37059] Re: [Feature #735] Date#inspect"
on Tue, 11 Nov 2008 06:59:30 +0900, Tadayoshi Funaba [e-mail] writes:

|> どこかに妥協点があるとよいのですが。ただ、私はinspectがto_s
|> と同様の「人間にわかりやすい日付(DateTimeの場合は時間も)」の
|> 表現 も 含むことを期待します。
|
|長いですけど、
|
|#<DateTime: 2008-11-11T00:00:00+00:00 (4909563/2,0,2299161)>
|
|こんなんでもいいですか。

いいんじゃないでしょうか。

|別ものとして Object#examine とかで smalltalk の inspect 相当の目的で
|
|#<クラス名: to_s (インスタンス変数の内容)>
|
|のような内容を返すものがあればそのほうがいいのかも。

インスタンス変数の内容だけでは判別つかないものもありますが、
役に立つ局面もあるでしょうね。

=end

[mame (Yusuke Endoh)]

=begin
遠藤です。

2008/11/11 19:27 Yukihiro Matsumoto [e-mail]:

|2008/11/10 5:23 rubikitch . [e-mail]:
|> 「inspectは人間に優しい文字列化」という観点から、Date#inspectの出力はふさわしくないと思います。
|> #<Date: 2008-11-10> やら #<DateTime 2008-11-10T05:22:03+09:00> のほうがわかりやすいです。
|
|最終的には yugui さんの判断によりますが、これは完全に仕様変更なので
|1.9 系列には導入するべきでないと思います。
|そして yugui さんはこれを許可すべきでないと私は思います。
|
|すごく良い提案だと思うので、個人的にも残念ではありますが……。

最初の方針通り、変更はtrunkに行われるべきです。そしてその変更
を1.9.1に取り込むかどうかの判断はYuguiさん(だけ)が行います。

私は以下のように認識していました。

• 1.9 系列の間で非互換な変更は行わない
• 現状では trunk が 1.9 系列である

ゆえに、ruby_1_9 のブランチが切られるまでは trunk でも変更しては
いけないものと考えました。私の勘違いでしょうか。

--
Yusuke ENDOH [e-mail]

=end

[tadf (tadayoshi funaba)]

=begin

最終的には yugui さんの判断によりますが、これは完全に仕様変更なので
1.9 系列には導入するべきでないと思います。
そして yugui さんはこれを許可すべきでないと私は思います。

じゃ止めましょうか。

String#inspect を String#dump のように使う人が減らないという話も
あるので、明示的に

• 組み込み・添付ライブラリ内の inspect はすべて未定義挙動である
  • デバッグ時にのみ「人間によみやすい文字列化」を行うことを期待
    してよい
  • 最終的にその挙動 (や戻り値) に依存したコードを書いてはならない
  • (そもそも未定義挙動なので言うまでもないが、挙動は常に変更されうる)

という仕様にしとけばよかったですねえ。

どちらかというと僕はそういうもんだと思っていました。ここはカプセル化に
よる隠蔽などの例外なので実装の都合で変化しうるものだと思います。
Object#inspect の振舞いは、やはり smalltalk のそれと基本的に同じように
見えます。クラスベースの OOPL としてインスタンスの個性はインスタンス変
数の違いが基本になっていて (ruby ではそれだけじゃないですが)、それを覗
き見るということだと思うので。

ワークスペースや REPL での表示形式や inspect の意味などを念頭に少し練
り直したほうがいいのかも。

=end

[rubikitch (rubikitch .)]

=begin
From: Yukihiro Matsumoto [e-mail]
Subject: [ruby-dev:37057] Re: [Feature #735] Date#inspect
Date: Tue, 11 Nov 2008 00:56:59 +0900

|「inspectは人間に優しい文字列化」というのは初めて聞きました。現状では本

そもそもinspectの目的はデバッグ出力ですよね。pやirbの出力でも使われてい
ますし。人間が読むことを目的としている以上、人間に優しい（わかりやすい）
文字列化というのは間違っていないと思います。

dateライブラリ使用者の立場から、YYYY-MM-DD形式が含まれていると嬉しいです。

ここで、ふなばさんのおっしゃることもよくわかるのですが、個人
的にはDate#inspectがto_sに近い書式であったらなあ、と思ったこ
とが一度ならずあります。確かにDate#inspectではすべての情報を
提供しているのですが、それが人間世界(？)でどのような意味を持
つかということが読み取りにくいからです。

私のように単に「ある日」を指すオブジェクトとして使うことの方
が圧倒的に多い人には現在のinspectの情報は「やさしい」とは言え
ませんね。pで出力させても何日なのかわからないからです。結局
to_sで表示し直すことになるという。でも、Dateそのもののデバッ
グには現在の方がうれしいでしょうね。

おっしゃる通りです。

どこかに妥協点があるとよいのですが。ただ、私はinspectがto_s
と同様の「人間にわかりやすい日付(DateTimeの場合は時間も)」の
表現 も 含むことを期待します。
^^

require 'date'
today = Date.today # => #<Date: 4909563/2,0,2299161>
today.to_s # => "2008-11-11"

この例ならば
#<Date: 2008-11-11 4909563/2,0,2299161>
とかどうでしょうか？

--
rubikitch
Blog: http://d.hatena.ne.jp/rubikitch/
Site: http://www.rubyist.net/~rubikitch/

=end

[yugui (Yuki Sonoda)]

=begin
yuguiです。

Yusuke ENDOH さんは書きました:

私は以下のように認識していました。

• 1.9 系列の間で非互換な変更は行わない
• 現状では trunk が 1.9 系列である

すみません、アナウンスをサボってました。1.9.1リリースまでに出せばいいか
な、と。
いつだったかの開発者会議で決めたんだったと思いますが、

• 1.9.xと1.9.yでのバイナリ後方互換性維持は諦めました。

どうせMVMやら何やらでいずれABIは変わります。また、1.9.1の開発が思ったよ
りも収束しませんでした。それでも、むやみに大きな非互換性は避けるべきです。
また、1.9.xのいずれかの時点で「これでfix」と言えたら嬉しいとは思います。

• 1.9.xと1.9.yの間でのRubyレベルの大きな後方非互換は避けるべきです。

• 1.9.x-pXXXと1.9.x-pYYYの間では、勿論バイナリ互換性、Rubyレベルでの後方
  /前方互換性を保つべきです。

よって、大きな非互換でなければtrunkで修正するのはあり得ます。

また、Object#inspectに特定の形式であることを望むべきでないのはもともとそ
う言う仕様だったと認識しています。よって、そもそも出力形式の変更は非互換
な変更ではないのではないでしょうか。Stringを返している限り。

なお、このスレッドを知らずに「これは仕様変更ではない」という認識で

うっかりDate#inspectの変更を1.9.1に取り込んでしまいました。

しばらく議論の推移を見て、必要ならばr20209にならってrevertしようと思い

ます。

--
Yugui [e-mail]
http://yugui.jp
私は私をDumpする

=end

[mame (Yusuke Endoh)]

=begin
遠藤です。

2008/11/11 20:23 Tadayoshi Funaba [e-mail]:

最終的には yugui さんの判断によりますが、これは完全に仕様変更なので
1.9 系列には導入するべきでないと思います。
そして yugui さんはこれを許可すべきでないと私は思います。

じゃ止めましょうか。

String#inspect を String#dump のように使う人が減らないという話も
あるので、明示的に

• 組み込み・添付ライブラリ内の inspect はすべて未定義挙動である
  • デバッグ時にのみ「人間によみやすい文字列化」を行うことを期待
    してよい
  • 最終的にその挙動 (や戻り値) に依存したコードを書いてはならない
  • (そもそも未定義挙動なので言うまでもないが、挙動は常に変更されうる)

という仕様にしとけばよかったですねえ。

どちらかというと僕はそういうもんだと思っていました。

そういうコンセンサスがあるのはそうだと思うんですが、コンセンサスと
仕様は違うと思いました。

が、IRC で聞いたところ yugui さんの考えでは「これはコンセンサスではなく
もともとそういう感じの仕様だった」ということみたいなので、変更していい
みたいです。1.9.1 にも取り込まれてました。

なのでどうやら私の早とちりのようです。ごめんなさい。

--
Yusuke ENDOH [e-mail]

=end

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Closed

[Glass_saga (Masaki Matsushita)]

• File deleted (QQ截图20120504205207.png)