From: "A. S. Bradbury" <asbradbury@...>
Date: 2006-07-06T01:45:09+09:00
Subject: Re: [SOC] progress on "Automated Wrapper Generation for Information Extraction"

On Wednesday 05 July 2006 16:50, Justin Bailey wrote:
> On 7/4/06, A. S. Bradbury <asbradbury@tekcentral.org> wrote:

> 3. Which is better?
>
> > (a). doc_tree = Ariel::StructureNode.new {|r| r.comment_list}
> > (b). doc_tree = Ariel::StructureNode.new {|r| r.comments :list}
> > (c) doc_tree = Ariel::StructureNode.new {|r| r.list :comments}
> > It's certainly possible for (a) and (b) to both be allowed.
>
> I prefer (a), though (c) seems intriguing. It sort of implies the interface
> for Ariel objects is always the same (get a single item, get a list, etc)
> and you just pass different symbols in. That could make it harder to
> introspect against, though. For any of these interfaces you should strive
> to make sure actual methods are implemented and its not just a lot of
> method_missing tricks. Actual implementations are a lot easier to deal with
> when meta-programming than hacking around method_missing logic.

I sent my last email a little early, I was going to mention method_missing. 
The way I'm using method_missing right now is to check if it's a normal node 
or a list, and then add the correct type of child accordingly. StructureNode 
is inheriting from OpenStruct which will very handily take care of adding 
methods.

On a side note, my initial implementation was using instance_eval to allow you 
to do:
doc_tree = Ariel::StructureNode.new do
  title
  timestamp
  author
  post_body
  comment_list do
    comment_author
    comment_title
    comment_body
    comment_date
  end
end

Kind of like Markaby. Using instance_eval makes the implementation somewhat 
messier and harder to debug, but this form does seem a little prettier. On 
the other hand, defining a context such as r.comment_list do |c| might make 
it more likely people will write what they mean when describing a structure? 
Perhaps not.

Alex