From: Clifford Heath <cjh_nospam@...>
Date: 2003-06-27T17:04:59+09:00
Subject: Magic at class-definition time

In an interview on http://www.codegeneration.net/>, Pragmatic Dave
showed some interesting tricks. The article has a long URL, so use
<http://tinyurl.com/fek8>. He says:

 > on a recent project, I decided to wrap access to the underlying
 > database scheme in a set of persistence objects. Ruby let me 
construct > a library which effectively extended the Ruby language:
 >
 > I could write:
 >
 >     class RegionTable < Table
 >      table "region" do
 >        field autoinc, :reg_id,        pimary_key
 >        field int,     :reg_affiliate, references(AffiliateTable, :aff_id)
 >        field varchar(100), :reg_name
 >      end
 >     end

I have a related need, to reflect an SQL schema in Ruby objects,
and thought that Ruby classes like this would be cool, so I tried
and succeeded in doing some of what Dave did - for an example, I
can do:

class InventoryReport < Table
     field :ComputerName, varchar(256)
     etc ...
end

There's a few things I don't get about Dave's example though, so
perhaps he or someone else would explain?

Firstly, I can see that he wanted the class name and the table name
to differ, so used a class method Table.table() - and that's fine.

The method takes a block however, and the block contains a series
of calls to a field method, presumably Table.field(type, symbol, *args).

I'm guessing that "field" defines methods for the current class
instance. In this case does "field" have to eval a string with
the method definition in it or is there a better way?

Why did Dave call "field" from a block attached to "table", instead
of just from the class RegionTable?

Clifford Heath.