Giles says It's Not Meta, It's Just Programming. Darn straight! The specific example he gives is the ability to add methods to specific instances, instead of to an entire class. As he demonstrates, this is invaluable for isolation when testing.
# written this way to demonstrate eigenclass syntax
class << @response
def body
({:foo => "bar"}.to_xml(:root => "thing"))
end
end
Combine eigenclass methods with open classes, and almost any idiom can be automated. If you regularly add stubbed instance methods for testing purposes, why not write a helper for just that? For many common tasks, including this one, the work is already done. Here is a more literate version of the above code:
# exact syntax depends on your choice of mocking library @response.stubs(:body).returns(some_canned_response)
If you are a n00b, this power is scary. Once you start treating code as data, the elegance of your code is dependent on your skill. You cannot hide behind the limitations of your programming language anymore, because there aren't any.
I was confused after reading Gile’s post first, as to why he didn’t just stub on the instance. It reads much more intentional to just your mocking tools stubbing capability, instead of having the noise of opening up the metaclass of the response instance.
I think Giles was demonstrating the feature under the feature, i.e. how you could roll-your own.
You can achieve the same level of readability in EasyMock without throwing away type information. Real skill is enabling code like this without throwing the baby out with the bathwater.
Bob, type information is orthogonal to the point here. “Code as data” is a powerful idea regardless of how you approach typing.
I was responding to, “you cannot hide behind the limitations of your programming language anymore, because there aren’t any.” Limitations can be a good thing, and for a skilled programmer, this particular example doesn’t necessitate a language with none. Also, when it comes to treating code as data, Ruby does indeed have limitations compared to Lisp.
Bob, your insight on Lisp is shattering. Neither I nor anybody else on the web had ever noticed that Lisp was a good language for treating code as data. :-)
Is that all you could come up with? ;-)
Wonderful! Another new and powerful way to make any language just as reliable and suitable to large-scale development as Javascript is, with the commercial success of lisp… Oh, wait.
Except in very special cases (e.g. debugging, certain unit tests) many of these features that bypass “limitations” are actually roads to madness when the developer team size is n>3.
“Once you start treating code as data, the elegance of your code is dependent on your skill.”
And the maintainability and stability of your code is inversely proportional to your ego :P