しばらく原稿に追われてRubyをいじる暇がなかったので、 反動としてRubyについて考えてみる。こういう時間が一番充実しているような気がする。
関数とレコードをベースにオブジェクト指向プログラミングをエミュレートするPythonと違い、 オブジェクト指向プログラミングによって関数をエミュレートするRubyでは、 lambdaはあっても、呼び出しが格好悪い
f = lambda{|x| p x}
f.call(12)
と「.call」が必要だからだ。気持ちとしては
f = lambda{|x| p x}
f(12)
と書きたいものだ。そこで
というルールを導入するのはどうだろうか。以前にも同じようなことを考えたのだが、
こともあり、あまりうまくいかなかった。 今回の条件であるローカル変数があるかないかならコンパイル時に判断できるので、 実害は少ないような気がする。
欠点はローカル変数名と同じ名前の手続きが呼べなくなることだ。 通常あまり問題になることはなさそうだが「p」のような重複しやすいものもあるしなあ。
なにか回避策を用意すべきだろうか。
Ruby流DIコンテナNeedleの開発者であるJamis Buckが5年間プログラマーとして働いたBYUを辞めて、 Ruby on Railsを開発したDHHの 37signalsに転職するという話。
在宅で仕事をするらしいのだが、 アメリカのプログラマの流動性を感じさせる一件。 また、Rubyが人の人生を変えるのを見るとなんとも言えない気持ちになる。
彼の成功を祈る。
This work is licensed under a Creative Commons License.
@p = lambda{...}; @p() は救いませんか。
現時点では救わなくてもいいんじゃないかなあって思ってます。救いたいという積極的な理由があれば考えます。
結局<br>f = lambda(:p){|x| p x}<br>f.p(12)<br>は無しでしょうか?
インスタンス変数は、define_methodがあるので必要性は低いんじゃないでしょうか。<br>野分案は、今まで特異メソッドやdefine_methodでやっていたことも簡単にかけそうですし、いいと思います。
野分案は秀逸なアイディアだと思うんですが、「lambdaが返すもの」(要するに「関数」)の性質としては違和感があるんですよねえ。なんか別の名前のクラスとしてなら導入してもいいと思うんですが。
Delegate?(笑)<br>は使ってるから…<br>AdaptorとかThunkとか。
というか、Procのサブクラスじゃなきゃいけないってことはないかも。<br>module Kernel<br> def attach_method(*m, &p)<br> (class << self; self; end).class_eval do<br> m.each {|i| define_method(i, &p)}<br> end<br> self<br> end<br>end<br>class Adaptor<br> def initialize(*m, &p)<br> super(&nil)<br> attach_method(*m, &p)<br> end<br>end
あとはClosureとかBlockとかですかね……微妙に違和感ありますけど。<br>Mimic、Emulator、Imitationとかいうのも面白いかも。<br><br>Procの派生クラスだと便利そうですね。