Best practices for Ruby Meta-programming

[harshal]

Dear all,

Ruby meta-programming is a real fun.
However no power comes without responsibility, so does the Ruby's meta-
programming.
Can anybody share the experiences with meta-programming (for example,
in writing DSLs.) so that if possible we can come up with best
practices?
It would be great if somebody is already aware of such best practices.

Thanks.

Warm regards,
Harshal

 

[Bil Kleb]

Hi,

Can anybody share the experiences with meta-programming (for example,
in writing DSLs.) so that if possible we can come up with best
practices?

Martin Fowler is crafting a book along these lines:

http://martinfowler.com/dslwip/

Regards,

 

[James Britt]

Dear all,

Ruby meta-programming is a real fun.
However no power comes without responsibility, so does the Ruby's meta-
programming.
Can anybody share the experiences with meta-programming (for example,
in writing DSLs.) so that if possible we can come up with best
practices?

Don't be evil.

Don't be stupid.


I think that about covers it.

 

[Avdi Grimm]

Don't be evil.

Don't be stupid.

So THAT's what I've been doing wrong all this time. Wish someone had
clued me in sooner.

My concrete contribution to this discussion:

Modules are your friend. When tempted to dynamically extend a class
with new methods, consider adding them to a module instead
(potentially a dynamically created module using Module.new). Then use
#include or #extend to add the module to your target. This has a
number of benefits, including:

* Clients can clearly see which which methods come from your
extension vs. the methods that are part of the class itself, by using
Ruby's reflection.
* Clients can override dynamically created methods and still reuse
them with #super() - no need to resort to aliasing.
* A module can be re-used for either class-wide extension or
extending a single object.

 

[harshal]

That's absolutely true.

It reminds me Einstein's quote "Make it simple, no simpler" (or
similar).

I think 'Module'-related suggestion is a good beginning.
Some of the best practices would still be valid from traditional OOAD.

However, the place where Ruby differentiates itself from traditional
programming languages is - Meta-programming.
So I am expecting few 'new patterns' just because of meta-programming.
I could not get any chance to look at the book 'Design patterns in
Ruby'.

Thanks.

Harshal

 

[Avdi Grimm]

However, the place where Ruby differentiates itself from traditional
programming languages is - Meta-programming.

If Ruby differentiates itself it's in the form of a particularly
expressive syntax, or maybe in the way it brings an amalgam of different
language features together. Metaprogramming itself is nothing new.
Heck, I used to do metaprogramming in C++.

 

[M. Edward (Ed) Borasky]

If Ruby differentiates itself it's in the form of a particularly
expressive syntax, or maybe in the way it brings an amalgam of different
language features together. Metaprogramming itself is nothing new.
Heck, I used to do metaprogramming in C++.

Hell ... I've done metaprogramming in macro assembler and FORTRAN.

 

[Paul Mckibbin]

Metaprogramming. Isn't that just another name for self-modifying code.
Only had to do that once in a game to get past a hardware limitation on
frame-flyback time for a display driver. (Had to split the screen into
1/3rds to get the maximum number of hardware sprites to treble ) That
was really the only time I *had* to do it and could justify it
convincingly since we were down to counting t-states.

<FXucks behind sofa and sobs quietly>

 

[Robert Dober]

Metaprogramming. Isn't that just another name for self-modifying code.
Only had to do that once in a game to get past a hardware limitation on
frame-flyback time for a display driver. (Had to split the screen into
1/3rds to get the maximum number of hardware sprites to treble ) That
was really the only time I *had* to do it and could justify it
convincingly since we were down to counting t-states.

<FXucks behind sofa and sobs quietly>

Duck is good, if you really go to the extremes of Ducktyping you need
metaprogramming in Ruby. Modules and Classes just wont do, hopefully I
will have time soon to elaborate on this.
Cheers
Robert

 

[Pedro Del Gallego]

programming (for example,

in writing DSLs.) so that if possible we can come up with best
practices?
It would be great if somebody is already aware of such best practices.

Don't overuse method_missing, it can be conflictive with other
frameworks and dsl in your application.