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