Metaprogramming conventions

[Avdi Grimm]

[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

[Pit Capitain]

Avdi Grimm 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 Weirich 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