From: dblack@...
Date: 2006-04-23T21:20:53+09:00
Subject: Re: Metaprogramming Conventions

Hi --

On Sun, 23 Apr 2006, Daniel Schierbeck wrote:

> Recently, there was a post on news:comp.lang.ruby[1] by Avdi Grimm, who asked 
> if there were any conventions when using metaprogramming. He gave this 
> example:
>
>  require 'memoize'
>  require 'validate'
>
>  class Foo
>    attr_accessor :bar
>    memoize :bar
>    validate :bar do |value|
>      value.include? "Johnny Walker Black Label"
>    end
>  end
>
> Disregard the fact that you rarely want to memoize a writer method.
>
> How do I know if memoize and validate play nicely together?
>
> There has already been a proposal that would make it very easy to add 
> metaprogramming capabilities without treading on each other's toes[2], but it 
> would be a very big step.
>
> A simpler solution would be to add a special method definition (an advice), 
> that had a `super' that called the *previous* definition of that method.
>
>  class Foo
>    attr_accessor :bar
>
>    advice bar
>      '[' + super + ']'
>    end
>
>    advice bar
>      '{' + super + '}'
>    end
>  end
>
>  foo = Foo.new
>  foo.bar = 'baz'
>  foo.bar        #=> {[baz]}
>
> That way, the user could choose in which order the wrapper methods should be 
> called.

"super" is not the best term, though: it means "next highest up in the
method lookup path" (i.e., in a different class or module), whereas
you're describing something that's lexically above but semantically on
the same level.  It's more an alias-related operation than a super
one, though not exactly that either.

Also, it seems a little fragile to me.  It would introduce a whole set
of constraints on the order of code and even the order of
file-loading.


David

-- 
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" PDF now on sale!  http://www.manning.com/black
Paper version coming in early May!