I think Kaspar is saying that you can pass content into your rules from passing a hash to your apply method.
This hash then gets treated like the result of matching a rule, so you can access the ":document" key as part of your passed in hash, or as a member of the class directly if your block doesn't take a parameter. *I'd have to check the code to verify this last statement. It's my interpretation of Kaspar's response.* * * *Nigel* --- "No man is an island... except Philip" On Thu, Apr 11, 2013 at 7:39 AM, Thomas Ingram <[email protected]>wrote: > I'm really confused now. What is Document, and what does #add_foo do? Also > what do you mean by "don't mix your code into the transformer"? Please > elaborate on this. > > My approach is to produce a rough parse tree, then normalize this into the > parse tree I really want, then transform the normalized parse tree into the > syntax tree. As I'm going along, I'm finding things to tweak in one or both > parse trees, but this seems to be working really well for me. The primary > reason for the normalization step is because I couldn't parse method chains > and operators (like in ruby) the way I wanted to, and Nigel Thorne > suggested I take a more layered approach. > > > On Wed, Apr 10, 2013 at 2:42 AM, Kaspar Schiess <[email protected]> wrote: > >> > On another note it looks like the rule blocks are being class eval'd, so >> > my `origin` instance method isn't even in scope. I'm passing it in when >> > I call #apply, but is there a better way? >> >> Class eval it is. But really, don't mix your code into the transformer, >> rather create a document that you pass around. Concerns like to be kept >> well apart. >> >> Here's how that might look like: >> >> doc = Document.new >> transform.apply(int_tree, document: doc) >> >> and in your rules: >> >> rule(:foo => simple(:foo)) { document.add_foo(foo) } >> rule(:foo => simple(:foo)) { |dict| >> dict[:document].add_foo(dict[:foo]) } >> >> I realize that there is next to no documentation for this, but I >> consider it an official feature! And hey, the mailing list is a start, >> perhaps someone wants to contribute documentation for a change? >> >> real nice greetings >> kaspar >> >> >> >> > > > -- > Thomas Ingram >
