Comments on: Class Methods Part II - Annotations http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/ Ruby and otherwise by Patrick Farley Sat, 13 Mar 2010 19:24:26 +0000 http://wordpress.org/?v=2.2.3 By: pfarley http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-151 pfarley Mon, 12 Nov 2007 22:57:25 +0000 http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-151 Hi Johnny, Took a couple weeks off. Thanks for the nice example. Hi Johnny,

Took a couple weeks off. Thanks for the nice example.

]]> By: Johnny P http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-148 Johnny P Wed, 07 Nov 2007 19:00:17 +0000 http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-148 Well I found an answer to my own comment. >> module E >> def accept_only(sym, &body) >> define_method(sym) { |*args| puts args.inspect; body.call(*args) } >> end >> end => nil >> class TestSomething >> extend E >> accept_only :setup_something do |x| ?> puts x + 2 >> end >> end => # >> t = TestSomething.new => # >> TestSomething.instance_methods(false).inspect => "[\"setup_something\"]" >> t.setup_something(1) [1] 3 => nil Well I found an answer to my own comment.
>> module E
>> def accept_only(sym, &body)
>> define_method(sym) { |*args| puts args.inspect; body.call(*args) }
>> end
>> end
=> nil
>> class TestSomething
>> extend E
>> accept_only :setup_something do |x|
?> puts x + 2
>> end
>> end
=> #
>> t = TestSomething.new
=> #
>> TestSomething.instance_methods(false).inspect
=> “[\”setup_something\”]”
>> t.setup_something(1)
[1]
3
=> nil

]]> By: Johnny P http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-140 Johnny P Tue, 30 Oct 2007 17:16:04 +0000 http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-140 Patrick, great blog entry, thanks. Just wondering after reading how the "Annotated Method Declaration" has access to the parameters passed? You mentiion this as a distinguishing point, but don't actually show it. I cannot see how "acceptance_only :test_some_complex_calculation do" has any parameters to the new method test_some_complex_calculations, and I am not sure how it could. The only thing I came up with was something heading toward simplexity and that is to actually define two methods. The first would accept *args and then do whatever with them and then call the "acceptance_only" method. Is there another way? Thanks Patrick, great blog entry, thanks. Just wondering after reading how the “Annotated Method Declaration” has access to the parameters passed? You mentiion this as a distinguishing point, but don’t actually show it.

I cannot see how “acceptance_only :test_some_complex_calculation do” has any parameters to the new method test_some_complex_calculations, and I am not sure how it could. The only thing I came up with was something heading toward simplexity and that is to actually define two methods. The first would accept *args and then do whatever with them and then call the “acceptance_only” method. Is there another way?

Thanks

]]> By: pfarley http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-137 pfarley Tue, 30 Oct 2007 03:54:01 +0000 http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-137 Hi Daniel, Thanks again for your comment. If I were eliminating things left and right I might do something like below, but my tolerance for this sort of thing is pretty high as long as the methods are short and the source is in a reasonable place... def self.exclude(platform_expression) @excluded_test = platform_match? platform_expression end def self.platform_match?(platform_expression) !platform_expression.find { |key, value| const_from_sym(key) && const_from_sym(value) }.nil? end def self.const_from_sym(sym) Kernel.const_get(sym.to_s.upcase) end exclude :windows => :jruby def test_something_jruby_doesnt_support_on_windows end Hi Daniel,

Thanks again for your comment. If I were eliminating things left and right I might do something like below, but my tolerance for this sort of thing is pretty high as long as the methods are short and the source is in a reasonable place…

def self.exclude(platform_expression)
@excluded_test = platform_match? platform_expression
end

def self.platform_match?(platform_expression)
!platform_expression.find { |key, value| const_from_sym(key) && const_from_sym(value) }.nil?
end

def self.const_from_sym(sym)
Kernel.const_get(sym.to_s.upcase)
end

exclude :windows => :jruby
def test_something_jruby_doesnt_support_on_windows

end

]]> By: Daniel Berger http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-135 Daniel Berger Mon, 29 Oct 2007 21:48:06 +0000 http://www.klankboomklang.com/2007/10/26/class-methods-part-ii-annotations/#comment-135 Oh, heck, maybe I should have used annotations for my personal Ruby test suite. Right now I'm just doing: if WINDOWS def test_something ... end end Annotations would look better for the simple case. But, then I have times where I do stuff like: if WINDOWS && !JRUBY def test_someting_jruby_doesn't_support_on_windows ... end end And that's just one of several combinations. I don't know that there's a generic way to handle that. At least, not one that's less ugly. Thanks again for a nice article, btw. Dan Oh, heck, maybe I should have used annotations for my personal Ruby test suite. Right now I’m just doing:

if WINDOWS
def test_something
…
end
end

Annotations would look better for the simple case. But, then I have times where I do stuff like:

if WINDOWS && !JRUBY
def test_someting_jruby_doesn’t_support_on_windows
…
end
end

And that’s just one of several combinations. I don’t know that there’s a generic way to handle that. At least, not one that’s less ugly.

Thanks again for a nice article, btw.

Dan

]]>