ウイルス・スパイウェア検査・駆除 用ツール Dr.WEB CureIt! を無償配布中！
になるかどうか自信は無いのだが、 1.9でイテレータ系メソッドにブロックを渡さない時に返される Enumerable::Enumeratorクラスに、 外部イテレータとして使うことができるようにnextメソッドを追加した。
実装には最近YARVに追加されたFiberを利用した。 っていうか、Fiberって初めて使ったよ。 使いやすいような、使いにくいような。慣れてないせいかな。
追加したメソッドは以下の通り
また、Enumerable#zipメソッドは、以前は引数として渡されたEnumerableを to_aで配列に変換していたが、Enumeratorを外部イテレータとして使うことにした。 これで、無限列もzipの対象にできる。
あと、zipの挙動だが、今まではレシーバの要素数だけ繰返していたが、 今後は正式にレシーバと引数でもっとも少ない要素数だけ繰り返すことにした(今までも1.9ではArray#zipがそうなってた)。
これでgeneratorライブラリを使わなくても簡単に外部イテレータが使えて、 PythonやXtalに一歩近づいた。
開成高校の吉田投手は吉田くんの弟だったんだ(そんなわきゃない)。
それはともかく、誰にでも理解できる表現ができる人には あこがれちゃうなあ。いや、蛙男については必ずしも「誰にでも」とは 言えないかもしれないけど、 少なくともRubyよりは広い範囲に分かってもらえそう。
というわけで、実は蛙男商会も島根県の重要な地域資源(コンテンツ産業)と 見なされているらしいぞ。現在、蛙男さんはほとんど東京に居るみたいだけど。
データフォーマットに特化しているという点ではYAML、JSONと同じ方向性のように見える。 CSSの影響が強いので、そっち方面に慣れている人にはわかりやすいかもしれない。
採用面接で「どんだけ技術が好きか」という点を集中的に確認するという仙石さん、という話。
技術が好きならば、プログラミング技術は後でいくらでも延ばせるし、 お互いに幸福な関係が築けるだろう、と。 まあ、確かにうちで生き残ってる連中も、 技術好きで日常生活をコンピュータにたとえて下らない話をするのが好きな連中が 多いものな。
今後の採用の参考にしよう。
Gemstoneといえば昔一世を風靡したOODBMS。 これがJRubyやRubiniusから使えるようになる、という話。 私はその頃ObjectStoreを使ってたけど。
待て。JavaとのコネクションでなんでもできるJRubyは分かるが Rubiniusが出てて、なんで本家Rubyが対象にならないのか。不思議。
動的型を好む人(Dynamic Typer)と静的型を好む人(Static Typer)は プログラミングの別の側面を見ているのだろう、という話。
If I understand correctly, people who prefer static type systems tend to
think in terms of structural invariants of their programs, while people who prefer dynamic type systems tend to think in terms of their programs' behavior. I am convinced this is a personal preference, nothing more, nothing less. I guess that static typers have equal problems developing in dynamically typed languages as dynamic typers have developing in statically typed languages. I don't see a problem here: If the requirements are such that a focus on static correctness is important, it's probably better to employ a static typer, whereas if the requirements are such that dynamic flexibility is more important, the job should better be done by a dynamic typer. There is nothing wrong with specialization, we don't need a grand unified theory of program development.
そう言われてみればそんな気もする。
「ぬりかべ」のあの姿と言うのは伝統的なものだと思っていたのだが、 実は水木さんの創造だったのね。実際はこんな獅子のような姿であったとは。
で、この「Ｌ・トム・ペリー コレクション」のＬ・トム・ペリーってのは、 ペリー長老のことだね、きっと。戦後、進駐軍として日本にいたって聞いてたけど、 ここまで日本通だったとは。
意外。
素晴らしい！ >next
rewindは名案ですね。あんまり他では見かけたことがないのですが、まつもとさん自身の発想？
ありがとうございます。
rewindは残念ながら私のアイディアではありません。
Rubyには以前からgeneratorライブラリという外部イテレータライブラリが添付されているのですが、そのAPIにあったものです。
おそらくはgeneratorのメンテナであるknuさんによるアイディアだと思うのですが。
このnext/next?の定義だと、空集合の繰り返しが上手く処理できませんね。終了判定も面倒ですし。
nextは末尾ではnil(かあるいは末尾用オブジェクト)を返すようにして、現在の指しているオブジェクトが存在するかどうかを判定するexist?を追加した方が良いと思います。
RubiniusとはSmalltalkつながりとか? (元記事まだ読んでないですが)
Enumerator が Iterator の機能をあわせもつのはうれしいのかなぁ。Enumerator#iterator #=> Iterator 、ってやるのは、ちょっと冗長ですか。
e = 3.times{}; e.each{...}; e.next? #=> true なんて出来るのは気持ち悪い気がします。
野分さん、
上手く処理できない空集合の繰り返しとか面倒な終了判定とかが具体的にイメージできませんでした。むしろ、提案されているexist?の方が面倒に感じるんですが、気のせい？
iteratorメソッドとかで明示的にイテレータを作るのは冗長過ぎて使われないと思います。
気持ち悪いと言う指摘はEnumeratorがeachによる「列」とnextによる「列」の両方を持つからでしょうか。それならなんとなく分かるかも。eachがbreakで中断された時のnextが何を返すのかとか。
もしかしたら勘違いしているかもしれませんが、下記の２つは見分けつきましたっけ？
''.to_enum(:each_byte) #=> (1)
'a'.to_enum(:each_byte) #=> (2)
next?だと両方ともfalseになるかと思います。
また、exist?のようなメソッドがないと、(1)のようなケースで要素の存在を確認する方法が無いような気がします。
区別つきます。next?は「次」のnext呼び出しが例外を出すかどうかを判定するので、(1)ではfalse、(2)ではtrueになります。
「要素の存在を確認する方法」というのはよくわからないのですが、初回(またはrewind実行直後)のnext呼び出しで例外が起きれば(or next?がfalseならば)要素は存在しない、とみなして良いのではないでしょうか。
む？そうしますと、$を終端とすると
| $ ''.to_enum(:each_byte)
| a | $ 'a'.to_enum(:each_byte)
(1) (2) (3)
初回は(1)(何も指していない)状態で、nextで(2)に移行するということでしょうか？
＃iteratorとして使う場合は初回にnextを呼ばないと
＃要素にアクセスできない
これなら問題は発生しなさそうですね。
まあ、必ずnextを呼ばなくてはいけないのはムダな気がしますが……
そういうことです。
next以外に要素を取り出す手段がありません(currentとかない)から、無駄ということはないと思います。