タグ

ブックマーク / blog.yugui.jp (6)

  • ブロックによるRuby内DSLの起源 - 世界線航跡蔵

    時代とともにRubyの使われ方は変わってきましたが、いつの頃からか発生したDSLのホスト言語としての役割にはずっとお世話になってます。人に優しく、故にプログラマ以外にも優しく、これがとてもRubyらしくて好きな点です。 #ruby25th— Yuki Yugui Sonoda (@yugui) 2018年2月24日 僕にとってRubyはfluentdやchefのための言語ですが、プラガブルなOSSエコシステムであったり、強力なDSLを作りやすかったりするところにその魅力を感じます。特にfluentdは大好きなOSSで、Mackerel運営でもかなり参考にさせてもらっています。 #ruby25th おめでとうございます!— songmu (@songmu) 2018年2月24日 DSLは当に感動したところなんだけど、DSL開発ツールとしてのRubyが「発見」されたものなのか意図されたものな

    ブロックによるRuby内DSLの起源 - 世界線航跡蔵
  • APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵

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

    APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵
    isaisstillalive
    isaisstillalive 2016/01/07
    "うんざりするのは、Rubyのライブラリやフレームワークの劣化コピーを目にするとき"
  • Roleに基づくスタブライブラリ - 世界線航跡蔵

    オブジェクトが他のオブジェクトと相互作用するにあたり、そのオブジェクトの機能の全体が必要になることは少ない。むしろ、オブジェクトの提供する特定のRoleのみが見えるべきである。そのRoleを提供することのみを契約すべきである。 MVCアーキテクチャではControllerはModelに対してオブザーバとして振る舞うし、Viewに対しては何らかのメッセージソースとして振る舞う。MVC風webフレームワークではControllerはViewに対して、表示すべきデータを供給する役割だし、一方でHTTPリクエストの消費者として振る舞う。 さて、ある種の静的型付け言語ではこのRoleをinterfaceという言語要素で表すことができる。そして、契約違反はコンパイルエラーとして検出することが可能だ。その言語の上のフレームワークが、適切にinterfaceで契約を結んでいるかは別として。 これをRuby

    Roleに基づくスタブライブラリ - 世界線航跡蔵
  • Rubyのメタクラス階層について再び - 世界線航跡蔵

    承前 。 3ヶ月ばかり時間が空いてしまったけれども、 sumimさんの記事 に答えたいと思います。 yugui さんの図は、たしかにクラスと特異クラス(メタクラス)が揃って並んでいて見た目にはきれいなのですが、これだとクラスが整然と並んでこそいるものの、肝心のメタ階層がどうなっているかという情報のほうは、正直なところ、いささか得にくいものになってしまっています。 いいえ、これで良いのです。なぜって? これが私の図(下記再掲)で一番言いたかったことで、ただ、一般のメタクラスと#<Class:Class>を並べているのはいただけないかな。これはsumimさんのSmalltalk版の図を意識しすぎて、まずかったかなと思います。 図1: うん、やっぱり メタ階層がどうなっているかという情報のほうは、正直なところ、いささか得にくいものになってしまっています。 これは当たってるかもしれません。 図の修

    Rubyのメタクラス階層について再び - 世界線航跡蔵
    isaisstillalive
    isaisstillalive 2008/12/18
    メタクラス階層について
  • Rubyの呼び出し可能オブジェクトの比較 (2) - というよりコンテキストの話 - 世界線航跡蔵

    前回 は各オブジェクトの基的な特徴を見ただけで終わってしまった。今回はこれらをコンテキストという観点から見てみたい。 前回のまとめ 呼び出し外側のscopeblock中身戻り値 __send____send__不可能(そもそもコンテキストを保存していない)可能保持しないメソッドの戻り値 Method[],call参照不可能可能メソッド体とselfメソッドの戻り値 UnboundMethod不能参照不可能-体メソッドの戻り値 Proc[],call,yield参照可能不可能closureProcの最後の値 Continuation[],call-不可能「続き」戻らない Proc#callにおいてブロック付きの呼び出しが不可能であることは前回は記述しなかった。 sshiさんにご指摘いただいた 。 Procを作成するときに指定するブロック仮引数の記述は、メソッド定義の際の仮引数の記述にとて

    Rubyの呼び出し可能オブジェクトの比較 (2) - というよりコンテキストの話 - 世界線航跡蔵
  • Rubyの呼び出し可能オブジェクトの比較 (3) - なんかklassの話

    前回 はコンテキストの概念を眺めて、klassを理解することが必要だという話になったのであった。 klass class文の中では構築しようとしているクラスに対応するClassオブジェクトがselfとなっている。それに、class文の中でのクラスメソッド定義をみると、なんとなく、「デフォルトではselfに、指定すればそのオブジェクトに」というメソッド呼び出しにおけるレシーバー解決に似ている。 class Foo def self.class_method_hoge p :hoge end end class Bar def Foo.class_method_huga p :huga end def self.class_method_huga_of_bar p :huga end end このことを考えるとRubyでは、メソッドはselfに定義されると考えたくなるが、そうではない。実はこれ

    Rubyの呼び出し可能オブジェクトの比較 (3) - なんかklassの話
  • 1