[ruby-talk:10415] Re: Nested modules and classes?

[e-mail] (Clemens Wyss) wrote:
>
>STRATEGY PATTERN?

No.

>"Ben Tilly" <[e-mail]> wrote in
><[e-mail]>:
>
><<SNIP>>
> >    class RecDescent
> >
> >      # Try these rules in order
> >      class Alt
><<SNIP>>
> >
> >        def parse (str, pos=0)
><<SNIP>>
> >        end
> >      end
> >
> >      # Match all rules in turn
> >      class InOrder
><<SNIP>>
> >
> >        def parse (str, pos=0)
><<SNIP>>
> >        end
> >      end
> >
> >
> >      # And so on, more classes for each type of rule
> >
> >    end
> >
>Why not have a base (strategy) class, say RecDescentParseStrategy, on the
>"same level" as RecDescent and let Alt and InOrder (and ...) be
>subclasses of RecDescentParseStartegy? At least the attr_accessor and the
>initialize method could be inherited.
>
I am still writing test suites, etc for this, but at the
moment I have 7 classes, 6 of which correspond to types
of rules.  You happened to see the only two with a list
of other rules as attributes.

You are leaping to a generalization that isn't there.
The appropriate generalization (at least at the moment)
is that a rule shall have a parse method which is passed
a string and a position (which defaults to zero) and
returns output and a new pos.  An output of nil means
that it failed to match.

The types of rules that I have right now are the
following.  [Alt]ernative rules (match one of).  [Catch]
a parse error.  [Eat] (ie throw away) output from another
rule.  Try to [GetToken].  Match rules [InOrder].  Match
a rule [Rep]etitively (min to max times with a max of nil
being infinity, default to 0..infinity).

As you can imagine, the constructors and attributes vary
wildly...

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com