ruby-dev

斎藤と申します。
サイレントマジョリティたる rb_num_coerce_* ユーザの一人です。

On Wed, 4 Mar 2009 10:08:37 +0900
Nobuyoshi Nakada <[email protected]> wrote:

> r15437が問題になるのは、既存のインターフェースが1.8と変更になっ
> ているために、ソースレベルでの互換性をとるのが難しいからです。も
> しこれはそのままにするということであれば、インターフェースを確認
> するためのマクロを追加しようと思います。

このマクロというのは

#define RB_NUM_COERCE_FUNCS_NEED_3ARGS 1

みたいなものでしょうか?

もし1.9.2でAPIを変えるのであれば、拡張ライブラリ側で、extconf.tb中にtry_compile()として、
自前でAPIインターフェースのチェックを書くのは骨が折れるので、入れて頂けるととてもありがたい
です。これでまず、1.9.1 <=> 1.9.x間の拡張ライブラリの互換性の確保が将来、簡単になりますね。

また中田さんは「(r15437を)そのままにするということであれば」とおっしゃっていますが、
そのままに「しなくても」「1.8/1.9両ブランチに」ぜひ入れてもらいたいです。というのは、もう
1.8.xと1.9.1の間でrb_num_coerce_*のインターフェースが違うのはすでに確定している上、
1.8/1.9両対応の拡張ライブラリを作りたい身としては、どちらにせよtry_compile()が必要と
なるからです(もっと良い手段があったら教えてください)。

1.8から1.9過渡期の現在、両方に対応したライブラリを書きたいという要求は小さくないと思います。
また過渡期は、しばらく続くでしょう。

拡張ライブラリからAPIの違いを簡単にチェックできる手段を、1.9だけでなく1.8を含むすべての
ブランチに入れていただけるならば、1.9.1p0が古くなった時点で、拡張ライブラリを書く人間は
マクロのチェックだけで済むようになります。1.8から1.9.1への移行もやはり簡単になる、という
わけです。

いかがでしょうか。

On Wed, 4 Mar 2009 10:12:24 +0900
Yukihiro Matsumoto <[email protected]> wrote:

> |r15437が問題になるのは、既存のインターフェースが1.8と変更になっ
> |ているために、ソースレベルでの互換性をとるのが難しいからです。も
> |しこれはそのままにするということであれば、インターフェースを確認
> |するためのマクロを追加しようと思います。
> 
> とはいえ、1.9.1は出てしまっているので、どこかに非互換性が発
> 生するのは避けられませんね。

上述のとおり、もう1.8.xと1.9.1で非互換が発生しています。なので1.9.1と1.9.xで非互換が
発生しても、どっちみちチェックを行うので、あんまり関係というのが現役(?)拡張ライブラリ
作者の感覚です。
むしろその1.9.xの非互換が、1.8との互換性をとる方向の変更である (rb_num_coerce_* の
引数が二つになる) のならば、個人的には賛成です。

もともと「機能は増えないのに、引数として必要な情報だけ増える」という、うれしくない
方向のAPI変更でしたし。

--
斎藤ただし