Proposal Votes for “Prefix all classes with PEAR_”

こんなに議論があるとは思わなかった。確かに、今後PHPにSPLクラスが出てくる以上、DateやTimeなどの一般的な名前のクラスはなんとかならんかな、と思っていた。そのため、投票したのだが、議論がこれだけある以上、今回は見送るということが必要ではないか。私は自分が新参者と言っておきながら、+1票を投票をしたのだが、もう少し様子を見るべきだったと少し反省をしている。

さて、なぜ、こんなにRFCにおいて、マイナス票があるか、というとそこには、二つの論点がある。

A: QA Teamが足りていないこと。もしくは、いないことから、時期的にまずい、とのこと。

B: prefixが必要なのは、トップレベルのパッケージだけではいいのではないか、とのこと。

Aの件に関しては、QA Teamがいるにはいるのだが、今PEARで起きようとしている変化に対応できるのかってことが心配だということだ。もしくは、他にもやることあるだろ！とのことだ。現在、pearwebを作成しようとしているし、来年1月か2月からE_STRICTなパッケージしか受け付けないようにしようとしている。議論を見る限りでは、未だかつてない変化をしようとしているときに、QA Teamが今のままでは、とてもこのPEAR_というprefixを通すことは難しいのではないか、と。というのも、今後のメジャーバージョンアップや、新しいパッケージに全てPEARというprefixを付けようというRFCであるから、影響はとても大きいのだ。というか、ここが議論のタネであれば、私の勇み足だ。ぜんぜんQA Teamのことを考えていなかったから。

Bの件に関しては、そもそも問題となっているのは、DateやFileやDB、Mailなどのパッケージがprefixがなく、トップレベルに存在していることであって、すべてのパッケージが問題ではないということだ。確かにかつて、SPLクラスであるFileObjectクラスは、Fileという名前でリリースしていたのだが、PEARにFileクラスがあるために名前を変更したのであるということがあげられている。なので、全てにPEARのprefixはいらんだろ？っていうことだ。

Aの件から、また、これだけマイナス票や議論があることから、今は、prefixに関しては、置いておいていいのではないかと考えるようになった。しかし、いずれは、このprefixの問題はなんとかしてほしい。Bに関しては、Zendと議論がしきれていなかったのが問題なのかな。。。まぁ、言うのは易し、実行するのは難しなので、何も実行していない私が言及することではないのかもしれないが、もう少し観察必要でしたね。私としては、E_STRICTのRFCもこのprefixのRFCも出てきたころから注目していたので、議論は追いかけていたと思っていたのだが、prefixのRFCの方は議論が枯れていなかったのかな。。。

と言いつつも、まだ投票期間は終わってないので、どうなるかはまだわからない。私も傍観しているだけでなくて、せっかく投票権を持ち発言することができる立場なので、議論に入っていきたいと考えている。しかし、この議論のダイナミズムはすごいなー。追いかけるのが精一杯。

つーか、こんなに議論があるのなら、Proposalのフェーズでこの勢いで議論があったらなぁ。Proposalで、3ヶ月間あったわけだし。うーん。でも、DB2とかMDB2とかQuickForm2とかのネーミングよりもいいとは思うのだが。。