https://twitter.com/kinaba のログ (twilog の方が便利です。)
| るびまゴルフとりあえず34Bもしくは35B（入力仕様による）になった。もっと減りそう | |
| @niha28 今僕は問題を誤解することに関する第一人者なので大丈夫だと思います | |
| @keigoi さんの発表 http://www.ipl.t.u-tokyo.ac.jp/~tops/upcoming_seminar.html がアナウンスされてるのに今気づいた。興味のある方はいらっしゃるといいと思います | |
| @kmizu http://twitter.com/kmizu/status/2401663034 これってnon-finalなことは関係あるんでしょうか。untilのセマンティクスを"知って"いればRangeクラスそのもののインスタンスが返ることがわかるので、問題ないような | |
| ただ、Javaでもpublic static final intがインライン展開されてて時々困るのと同じで、そもそもインライン展開というもの自体が、相手のクラスの実装が挿し変わったときのセマンティクスと絡んであんまり適用しちゃいけないもの感がある。 | |
| @wraith13 @bleis です。ライブラリをversion upするときにインターフェイス全て同じでもpub.st.finの値が変わってると依存部分が全部再コンパイル必要。というか、p.s.fフィールドは名前だけじゃなくて値も含めてインターフェイスなんですよね、あれ。 | |
| メソッドの"実装"とはレベルが違うとゆーか。んで、メソッドのコンパイル時インライン展開を許してしまうとそれと同じ事がメソッドにも起きて、つまりAPIは同じで実装だけ変更したときも依存部分が全部再コンパイルが必要な楽しいライブラリが完成。 | |
| まあRangeのような言語の根幹のクラスの実装が変わったら全部再コンパイルでも誰も文句言わないとは思いますが… | |
| @kmizu なるほど。ただ、個別に知らせる必要はなくて、インスタンスの実行時の型を静的に解析しておいてvirtualな呼び出しを無くす、的な最適化が汎用に実装されれば、欲しいケースは大部分カバーされるんじゃないかという気が。g++ とかは実際そういう最適化をしてくれます。 | |
| （さっき書いたインライン展開そのものの問題のことはとりあえずさておくとすると | |
| @fkm yes. むしろ、インライン展開と動的/静的リンクの話、というか。 ・動的リンクの境界を越えた静的インライン展開はしちゃいけないと思う ・Javaの.classって基本的に動的リンク境界なので難しいよね、みたいな | |
| @kmizu ですです。たぶん解析と言ってもそこまで大がかりなことをする必要はなくて、数段メソッドの定義を潜ってベタに new Range(...) 式が出所とわかればその情報を使う、くらいで、あまり長距離の推論はしなくても実用的には十分そう | |
| @fkm VMが実行時に動的なインライン展開してくれるさ！という気分でいるのが良さそう | |
| ところでドラクエのスカラってなんでスカラって名前なんだっけ | |
| スクルトが先でそれのドラクエ的単数形か。スクルト… | |
| いつものフッタとわかってはいるけれど、RT:...(via @...)って書いてあるのに [要出典] と続いてるとなんともいえない面白さがある http://twitter.com/chunjp/statuses/2416594178 | |
| @kmizu @tanigon ここは日本で最も地に足のついてない勉強会ということで一つ |