ThoughtWorks does its best to attract smart developers. It's no easy task. How do you convince the smartest developers in the world to join a company that requires 100% travel (in the US anyway) and become consultants. It's a tough sell. I've always believed that people join because of the other people they'll be working with. And, of the ThoughtWorks employees that people want to work with, Marti
Ruby's open classes allow you define and redefine behavior pretty much at will; unfortunately, almost every option comes with caveats. The example below is a gateway class that defines a process method. For the purposes of the example, assume that we need to redefine the process method on Gateway itself and call the original process method.* Also, assume that Gateway is not our class, so we cannot
You have methods you want to handle dynamically without the pain of debugging method_missing. class Decorator def initialize(subject) @subject = subject end def method_missing(sym, *args, &block) @subject.send sym, *args, &block end end becomes class Decorator def initialize(subject) subject.public_methods(false).each do |meth| (class << self; self; end).class_eval do define_method meth do |*args|
Defining Methods Dynamically You have methods that can be defined more concisely if defined dynamically. def failure self.state = :failure end def error self.state = :error end becomes def_each :failure, :error do |method_name| self.state = method_name end Motivation I use Dynamically Define Method quite frequently. Of course, I default to defining methods explicitly, but at the point when duplica
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く