タグ

設計とRubyに関するzomyのブックマーク (3)

  • Big Sky :: Matz の「言語のしくみ」を読んだ。

    Twitter で「言語のしくみ」読みたいなって呟いたら Matz 人から「献しましょうか」とメンション頂いて即答でお願いしました。ありがとうございます。 ひさびさ紙のを通勤電車の中で立ちながら読んだので手がだるくなりました。なんだか懐かしい感じがしました。 さてこのですが、一言で言うとこんなです。 Ruby のパパこと Matz が雑誌の連載に追われながら試行錯誤して作ったプログラミング言語「Streem」を解説する 聞こえが悪かったらすみません。言いたいのはこの「試行錯誤」がとても良いエッセンスになっている点なのです。実際にはその連載記事をまとめた物に対して、この当時はこの様に考えていたが後になってみると実は良く無かったといった振り返り「タイムマシンコラム」で構成されています。 この連載が1つのに纏められた事でプログラミング言語設計者の葛藤が非常に良く表されているな、そう

    Big Sky :: Matz の「言語のしくみ」を読んだ。
  • APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵

    APIデザインケーススタディ 』というを頂戴したので読んでみた。 ライブラリ作者に向けて このRuby標準ライブラリを題材にして、分かりやすく、多様な機能をサポートして、互換性を保つAPIの設計をするにはどのように考えるべきかを教えてくれる。 ここでAPIと言っているのは、一般的なRubyのクラスとオブジェクトとメソッドから成るライブラリをどうデザインするか、という話である。 別にChef RecipeやRSpec DSLのようなちょっと変わったDSLを設計するとかそういう話ではない。確かにその種の言語内DSLのデザインには固有のセンスが必要とされるし、 Ruby DSL Handbook なんてが書かれているように実装にあたってもある種のテクニックが必要なのも確かだ。でも、それ以外の「ふつう」のライブラリのデザインは果たして簡単だろうか。 適切な粒度のクラスを定義する。必要な

    APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵
  • RubyでBoolClassではなくTrueClass/FalseClassな理由を理解する - Qiita

    @mattn_jp BoolClassを入れるとkind_of?でチェックしたくなってduck typingを阻害するから。 — Yukihiro Matsumoto (@yukihiro_matz) 2015, 12月 4 30回くらい読みなおしたけど何のことを言っているのか分からなかったので、周りのRubyistに質問して理解を深めたメモ。 まずDuck Typingというのは、Wikipediaによると ダック・タイピング(duck typing)とは、Smalltalk、PythonRubyなどのいくつかの動的型付けオブジェクト指向プログラミング言語に特徴的な型付けの作法のことである。それらの言語ではオブジェクト(変数の値)に何ができるかはオブジェクトそのものが決定する。つまり、オブジェクトがあるインタフェースのすべてのメソッドを持っているならば、たとえそのクラスがそのインタフェ

    RubyでBoolClassではなくTrueClass/FalseClassな理由を理解する - Qiita
  • 1