Comments on: Ruby and Metaprogramming http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/ Ruby and Ruby on Rails Development Fri, 09 Jan 2009 23:15:19 +0000 By: John W http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-394 John W Tue, 04 Dec 2007 04:26:55 +0000 http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-394 This is an excellent introduction.. I've been working with RoR for the last two years, and you've cleared a lot of things up. Big thank you. This is an excellent introduction.. I’ve been working with RoR for the last two years, and you’ve cleared a lot of things up. Big thank you.

]]> By: Free as in Time » Blog Archive » RoR Tuesday 19/06/2007 http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-77 Free as in Time » Blog Archive » RoR Tuesday 19/06/2007 Tue, 19 Jun 2007 16:09:39 +0000 http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-77 [...] is a topic new to me, and here’s a post that deals with Ruby and Metaprogramming. I’ll have to dig into that [...] [...] is a topic new to me, and here’s a post that deals with Ruby and Metaprogramming. I’ll have to dig into that [...]

]]> By: Seng Ming http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-75 Seng Ming Tue, 19 Jun 2007 06:16:24 +0000 http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-75 Great intro. I've been meaning to dive into metaprogramming for a while now and was glad to find this article. Great intro. I’ve been meaning to dive into metaprogramming for a while now and was glad to find this article.

]]> By: kamal http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-69 kamal Fri, 15 Jun 2007 02:16:48 +0000 http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-69 I think to make this a clearer post to people who are new to Ruby metaprogramming, I would suggest removing the cattr_reader example and just stick to the simple attr_accessor. The outline would roughly be: 1. Show the typical boilerplate code in Java where you need to write setters and getters to get at instance variables. 2. Show how to achieve the same thing in Ruby, with explicit #var, #var=(other) method. 3. Weave in the story about how you can use eval, to the point of evaling the entire def var, def var=(other) 4. Generalize it by wrapping the eval in a class method called attr_accessor and replacing the explicit "var" with the symbol that's passed in. 5. ??? 6. Profit! Also, worth noting the more cautious way to create methods on the fly is to use define_method and pass in a block. I think to make this a clearer post to people who are new to Ruby metaprogramming, I would suggest removing the cattr_reader example and just stick to the simple attr_accessor. The outline would roughly be:

1. Show the typical boilerplate code in Java where you need to write setters and getters to get at instance variables.
2. Show how to achieve the same thing in Ruby, with explicit #var, #var=(other) method.
3. Weave in the story about how you can use eval, to the point of evaling the entire def var, def var=(other)
4. Generalize it by wrapping the eval in a class method called attr_accessor and replacing the explicit “var” with the symbol that’s passed in.
5. ???
6. Profit!

Also, worth noting the more cautious way to create methods on the fly is to use define_method and pass in a block.

]]> By: Manuel Lemos http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-68 Manuel Lemos Thu, 14 Jun 2007 19:33:28 +0000 http://rails.aizatto.com/2007/06/15/ruby-and-metaprogramming/#comment-68 Metaprogramming does not to be done on the fly. Actually if you do it on the fly it means you will be making your program spend more time and memory to do something that actually may not need to change on the fly. For instance, you persistent objects model does not change at application runtime. So you do not need any metaprogramming done on the fly at runtime because you database schema will not change on the fly either. It would be much more efficient if you code generate ORM classes in a previous compilation step because you can optimize the code generation based on the knowlegde of the model that will not change at runtime. Metaprogramming in PHP is not a new thing. You may want to check the MetaL metaprogramming language site: http://www.meta-language.net/ Metastorage is PHP ORM classes code generation tool based on the MetaL compiler engine. It generates very efficient ORM classes that do not need a runtime library to perform ORM tasks because all optimizations are generated at compile time. The resulting classes are very compact and fast. The generated code is very clean and readable, as if it were a real human being that have written it. http://www.metastorage.net/ Metaprogramming does not to be done on the fly.

Actually if you do it on the fly it means you will be making your program spend more time and memory to do something that actually may not need to change on the fly.

For instance, you persistent objects model does not change at application runtime. So you do not need any metaprogramming done on the fly at runtime because you database schema will not change on the fly either.

It would be much more efficient if you code generate ORM classes in a previous compilation step because you can optimize the code generation based on the knowlegde of the model that will not change at runtime.

Metaprogramming in PHP is not a new thing. You may want to check the MetaL metaprogramming language site:

http://www.meta-language.net/

Metastorage is PHP ORM classes code generation tool based on the MetaL compiler engine. It generates very efficient ORM classes that do not need a runtime library to perform ORM tasks because all optimizations are generated at compile time. The resulting classes are very compact and fast. The generated code is very clean and readable, as if it were a real human being that have written it.

http://www.metastorage.net/

]]>