Best practices for Ruby Meta-programming

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

Hi,

harshal wrote:

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,

···

--
Bil Kleb
http://twitter.com/bil_kleb

harshal wrote:

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.

···

--
James Britt

www.risingtidesoftware.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys

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.

···

--
-------------------------------------
Pedro Del Gallego

Email : pedro.delgallego@gmail.com

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.

···

On Thu, Mar 6, 2008 at 1:15 PM, James Britt <james.britt@gmail.com> wrote:

Don't be evil.

Don't be stupid.

--
Avdi

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

···

On Mar 7, 12:19 am, Avdi Grimm <a...@avdi.org> wrote:

On Thu, Mar 6, 2008 at 1:15 PM, James Britt <james.br...@gmail.com> wrote:
> 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.

--
Avdi

harshal wrote:

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++.

···

--
Avdi

Avdi Grimm wrote:

harshal wrote:

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++.

--
Avdi

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