Forum: Ruby Metaprogramming Conventions

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Daniel S. (Guest)
on 2006-04-23 16:10
(Received via mailing list)
Recently, there was a post on news:comp.lang.ruby[1] by Avdi G., 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"

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 + ']'

     advice bar
       '{' + super + '}'

   foo = = 'baz'        #=> {[baz]}

That way, the user could choose in which order the wrapper methods
should be called.

Daniel S.

[2] <>
unknown (Guest)
on 2006-04-23 16:22
(Received via mailing list)
Hi --

On Sun, 23 Apr 2006, Daniel S. wrote:

>    validate :bar do |value|
> would be a very big step.
> 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


David A. Black (removed_email_address@domain.invalid)
Ruby Power and Light, LLC (

"Ruby for Rails" PDF now on sale!
Paper version coming in early May!
This topic is locked and can not be replied to.