A
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?=20
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
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?=20
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
