# Metaprogramming conventions

**URL:** <https://www.ruby-forum.com/t/metaprogramming-conventions/55904>\
**Category:** Ruby\
**Created:** [March 25, 2006, 12:00am UTC](https://www.ruby-forum.com/t/metaprogramming-conventions/55904 "2006-03-25T00:00:15Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![avdi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c6cbf5/32.png) [@avdi](https://www.ruby-forum.com/u/avdi)\
**Post date:** [March 25, 2006, 12:00am UTC](https://www.ruby-forum.com/t/metaprogramming-conventions/55904/1 "2006-03-25T00:00:15Z")

</div>

[Note: in the following I use the term “extension” to refer to any  
library which extends Ruby’s built-in classes, particularly the  
Module/Class classes.]

In Ruby we do a lot of cool metaprogramming tricks. In particular, we  
like to create class-level methods which declaratively “wrap” methods,  
as in the following hypothetical example:

```
require 'memoize'

class Foo
  attr_accessor :bar
  memoize :bar # cache bar's value unless it changes
end

```

Unfortunately, the way these metaprogramming hacks interact is  
typically undefined. E.g. if I decided that “bar”'s value should also  
be validated when it is set, I might use Alice’s hypothetical  
validator extension:

```
requier 'memoize'
require 'validate'

class Foo
  attr_accessor :bar
  memoize :bar # cache bar's value unless it changes

  # bar must be well-stocked at all times
  validate :bar do |bar|
                                bar.include? "Johnny Walker Black 

```

Label"  
end  
end

Will these two extensions, validate and memoize, play well together?  
I don’t know until I look at the source code. And because Ruby is  
such a flexible language, there’s a good chance that under the covers  
they are implemented in an incompatible way. And even if they work,  
they might clutter up the ‘Foo’ class in an unpredictable way -  
perhaps ‘memoize’ keeps the original function in a @@\_\_methods class  
variable, whereas ‘validate’ aliases the original ‘bar’ method to  
#\_old\_bar.

My question is, has anyone put any thought towards establishing  
conventions for metaprogramming, so that we don’t step on each other’s  
toes as we add more and more nifty declarative features to Ruby? Is  
there any interest in such an effort - coming up with an agreeable set  
of conventions for how to apply advice to methods, and how to store  
extension-specific data for objects/classes, and possibly creating a  
library that would hide the details of sticking to the convention?

I realize that Ruby 2.0 will likely make a lot of these issues go  
away, but in the interim it might be nice to have some conventions to  
keep Ruby extensions maximally interoperable.

~Avdi

---

<div class="post-metadata">

**Author:** ![avdi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c6cbf5/32.png) [@avdi](https://www.ruby-forum.com/u/avdi)\
**Post date:** [March 28, 2006, 7:03pm UTC](https://www.ruby-forum.com/t/metaprogramming-conventions/55904/2 "2006-03-28T19:03:41Z")

</div>

Avdi G. schrieb:

> My question is, has anyone put any thought towards establishing  
> conventions for metaprogramming, so that we don’t step on each other’s  
> toes as we add more and more nifty declarative features to Ruby? Is  
> there any interest in such an effort - coming up with an agreeable set  
> of conventions for how to apply advice to methods, and how to store  
> extension-specific data for objects/classes, and possibly creating a  
> library that would hide the details of sticking to the convention?

Jim W. schrieb in Re: Rails vs. Ruby Evolution:

> The moral of the story is: You need to be careful in creating libraries  
> that touch the “public” portions of Ruby. I’ve been meaning to write  
> down a few guidelines that I tend to follow, but haven’t had time yet.  
> I think the time is ripe for someone to codify a “How to play together  
> nicely in Ruby” set of guidelines.

Avdi and Jim, those are great ideas. Sorry, currently I have not more to  
offer, just wanted to support your thoughts 🙂

Regards,  
Pit