秘密じゃないよね。
Dave ThomasによるConstructor Methodの紹介ですが、 「コンストラクタをprivateにするのはどうか」という疑問の声を読みました (もう消えてしまったのでリンクできませんが)。
もちろんDaveがなにを考えていたのか分かりませんが、 私は「コンストラクタをprivateにする」価値があるケースはあると思います。
つまり、オブジェクトの複数の生成法があり、それぞれが同じように重要だった場合、 コンストラクタをprivateにしなければ、 「コンストラクタが採用している生成法がもっとも重要である」という 「正しくない暗黙のメッセージ」を与えてしまう可能性があります。 逆に言えばコンストラクタをprivateにすることにより、 「どれも同じように重要だ」という暗黙のメッセージを送ることになります。
良い設計というのは、こういう暗黙のメッセージが(意図してかどうかはともかく)、 うまく状況に即しているものではないのでしょうか。
経済産業省からお誘いのメールをいただき、さいわいにも東京にいたので、 経済産業省別館にて開かれた「Bruce Perensを囲む会」に参加しました。 お誘いのメールには「ランチミーティング」とありましたが、「ランチは出ません」とも書いてありました。 ランチタイムに開く会という意味だったようです。
で、行ってきました。言語は終始英語。 鵜飼さん、佐渡さん、八田さんなどをはじめとして(この業界で)有名な人もたくさんいました。
Perensの発表はなかなか説得力のあるものでした。たぶん、明日の内容と重複していると思うので、 どこかで資料が公表されるのではないでしょうか。
それから経済省のムラカミさんという方が話されました。
個人的には異論ありまくりなんですが、その点については後で本人と語りました(後述)。
集会後、Perensと個人的に話しました。
とかいうような話の後、Open Source Evangelistの備えるべき条件てどんなもんだろうか、 という質問をしました。
なるほど。Perens自身はElectricFenceやBusyBoxの開発経験があり、 また長らく映画業界(Pixer)にいたのでビジネスのことも分かるということなのでしょう。 こんな人、日本にいるかな。
最後にムラカミさんと話しました。私からは
というような話をしました。ある程度納得していただいたようで、 方針の転換を検討するという建設的な意見をいただきました。
いやあ、よかった。
This work is licensed under a Creative Commons License.
えーと、けんたろうさんとゆうぞうさんは従兄弟ではなかったかと・・・（うろおぼえ
new を private にすることに価値が存在する場合があることに反論するものではないですが、<br>それ以前に、ユーザにとって使いにくい new が作られがちな言語設計という話が<br>あるんじゃないかと思っています。<br><br>インスタンスの初期化コードを書くところは initialize ひとつしかないため、<br>inititalize とそれに直結した new は<br>インスタンス変数を自由に設定できるプリミティブなものになりがちです。<br>これは new 以外のコンストラクタが全て new を通してインスタンスを生成するからで、<br>例をあげれば、(昔の) Date でユリウス日を直接設定するとか、<br>Rational で約分せずに分子分母を設定するとかがあります。<br><br>ところが、こういうプリミティブな new は往々にして細かすぎて、<br>new という名前があたえる重要さ(というか気安さかな)にあっていません。<br><br>そういうミスマッチを修正するには、<br>private にするなり rename するなりの new をいじくる付加的なコードが必要なわけです。<br>しかし、そういうコードが無くても機能的に足りないわけではありませんから、<br>プログラマの怠惰さ(やミスマッチに対する鈍感さ)によってそういうコードが記述されないことが<br>多々あるのではないか、と思っています。<br><br>つまり、この件に関して Ruby は間違った暗黙のメッセージが生成されがちな言語<br>(長いプログラムよりも短いプログラムのほうが間違ったメッセージを生成しがちな言語)<br>なんじゃないかなと思うわけです。<br>まぁ、どうやったら直せるかというのは謎ですけど。
この件に関して正しい暗黙のメッセージを送る方が手間がかかる言語であることには同意します。<br>ただ、経験から考えると多くのクラスでは生成方法は非常に少なく(1つか2つ)、また整斉に優先順位をつけることができることも多いので、このようなケースの起きる頻度はかなり低かろうと思います。<br>このような低い頻度を助けるために全体のモデルが複雑になるのは避けたいです。いや、このようなケースにも対応できる全体として単純なモデルもありえるかもしれませんが、少なくとも私にはすぐには思いつきません。
VA Linux Business Forum 2003 で発表したのはこれでしょうね<br>http://perens.com/Articles/JapanJune2003.txt
頻度として、new 固定というのがうまくいかないケースより<br>うまくいくケースのほうが多いというのはそう思います。<br>ただ、かなり低かろう、とまでは思いません。<br><br>標準添付から即座に 2つ例を出せる(じつは Resolv::IPv4 とかもそうなのでもっとある)というのは<br>じつはそれなりにあるのではないかということを予感させます。<br><br>また、私が気にしているのは、整斉に優先順位をつけることができても、<br>その優先順位をメッセージとして発するために余計なコーディングを強いられがちという点です。<br><br>ただ、モデルの単純さが重要なのはもちろんで、<br>単純さを保ったまま直せるかというと私にも謎です。<br><br>まぁ、たとえこの件を解決できたとしても、<br>一般に全てを言語で解決するのは無理でしょうから、<br>「あえて長いコードを書いたほうが良い」ケースを<br>いろいろ集めて文書化するのが良いのかも知れません。