Chaps, We have a solution... I went for the option presented by Nigel Thorne, see https://gist.github.com/NigelThorne/4718832 for the gist.
Passing the date parser you want into the Shortee message parser worked a treat: https://github.com/JeremyNevill/shortee Cheers, Jeremy On 6 February 2013 15:31, Jonathan Rochkind <[email protected]> wrote: > Ah, neat, it hadn't occured to me to try that, thanks for the example! > > On 2/5/2013 6:50 PM, Nigel Thorne wrote: > > I haven't tried this code.. but I think something like this should work.. > > > > https://gist.github.com/NigelThorne/4718832 > > > > I'm trying to inject the number parser into the Json parser as an > example. > > > > > > --- > > "No man is an island... except Philip" > > > > > > On Wed, Feb 6, 2013 at 10:23 AM, Jonathan Rochkind <[email protected] > > <mailto:[email protected]>> wrote: > > > > "prefer composition over inheritance" is indeed a good principle. > > > > But I don't understand how you actually do what you're saying in > > this example, in practice. Can you provide a more complete example? > > Of two parsers that share most of their grammar, except for a > > different date rule? (Or am I misunderstanding that as the path to > > the goal?) > > > > I don't know how to get the bulk of the shared logic to be in two > > different parsers DRY, except using either inheritance or a mix-in > > (a mixin is really just a kind of inheritance too). Your example > > doesn't show this. But I'm curious to see how to do it, if there is > > a way! Can you share? > > > ------------------------------------------------------------------------ > > *From:* [email protected] > > <mailto:[email protected]> [[email protected] > > <mailto:[email protected]>] on behalf of Nigel Thorne > > [[email protected] <mailto:[email protected]>] > > *Sent:* Tuesday, February 05, 2013 6:02 PM > > *To:* [email protected] <mailto:[email protected]> > > *Subject:* Re: [ruby.parslet] International Date Formats > > > > I always favor composition over inheritance. (Think of it as > > the strategy pattern) see > > > http://stackoverflow.com/questions/243274/best-practice-with-unit-testing-abstract-classes/2947823#2947823 > > > > > > The key here is that rule definitions are nothing special. They are > > just methods that define methods that return parsers. :) > > > > The parser >> operator takes a parser and returns a parser.. so your > > rule body is just defining a parser too. > > > > You can even do stuff like this.. (thought I would prefer to pass in > > a date parser myself) > > > > def date_parser > > @region == :uk ? (day >> forwardslash >> ukmonth >> > > forwardslash >> year) : (usmonth >> forwardslash >> day >> > > forwardslash >> year) > > end > > > > and use it in rules like any other parser. > > > > rule(:shorteeshort) { > > (space? >> at >> actor.as <http://actor.as/>(:mainactor) >> > > action >> > > amountnum >> amountunits >> date_parser ).as(:shortee) > > } > > > > > > > > > > --- > > "No man is an island... except Philip" > > > > > > On Wed, Feb 6, 2013 at 9:15 AM, Jeremy Nevill <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi, > > > > Thanks for the quick replies… I think that the oo route is > > attractive as that would be easier to maintain and feel right. > > > > Here's my rather unsubtle excerpt for messages I know to be in > > UK format: > > > > rule(:shorteeukshort) { > > (space? >> at >> actor.as <http://actor.as>(:mainactor) >> > > action >> > > amountnum >> amountunits >> > > day >> forwardslash >> > > ukmonth >> forwardslash >> year).as(:shortee) > > } > > > > A lot of refactoring opportunity to be had… quite why I haven't > > extracted out the date format bit yet I don't know. > > > > Just for the record I've been doing a bit of performance testing > > on sending messages into my Shortee parser and it easily parsers > > about 300/second when hosted in a rails app on my Macbook Pro > > using MongoDB as the backend. > > > > Thanks again, most appreciated. > > > > Regards, > > > > Jeremy > > > > > > > > On 5 Feb 2013, at 21:58, Jonathan Rochkind <[email protected] > > <mailto:[email protected]>> wrote: > > > > > 1) Worth investigating the 'chronic' gem, rather than writing > > a parser > > > yourself. It can handle all sorts of natural language ish > > date formats. > > > > > > 2) But for your actual question. Parslet parsers are ordinary > > ruby > > > classes. They can inherit from each other, as well as use > > modules. > > > > > > So you could start out with an abstract parser class that > > lacks the rule > > > for dates, and then have two subclasses, US and UK, both of > > which > > > define their own date rule. > > > > > > Or you could use any other implementation sharing OO design. > For > > > instance, start out defining the US one as complete, then > > have the UK > > > one sub-class it and over-ride the relevant date rule. Or put > > the bulk > > > of your parser (without US/UK specific rules) in a ruby > > module, then > > > have both the US and UK ones 'include' that module, and > > supply their own > > > locale specific rules. > > > > > > I haven't actually tried any of these things recently, but > > they should > > > all work, something along those lines. That parslet parsers > > are just > > > ordinary ruby classes to which you can use ordinary ruby > language > > > composition features -- is one of the very strong points > > about parslet > > > in my opinion. > > > > > > On 2/5/2013 4:46 PM, Jeremy Nevill wrote: > > >> First of all, great parser and documentation which has > > helped me make the leap from regex to proper parsing. > > >> > > >> We're using Parslet it to parse our Shortee event message > > format, sample messages being: > > >> > > >> @JeremyNevill ate 1lambchop 01/02/2013 > > >> @JeremyNevill walked @Rover 3miles 12/dec/2012 > > >> > > >> I have the parser working nicely, extracting the message > > entities defined in my syntax: > > https://github.com/JeremyNevill/shortee > > >> > > >> Now the issue I have is how to handle ambiguous dates as we > > have both US date format and UK date format clients: > > >> > > >> e.g. 01/02/2013 in the UK is 1st/Feb/2013 but 2nd/Jan/2013 > > in the US > > >> > > >> At present I have 2 very similar parsers, one that handles > > UK dates, the other that handles US… this is not very DRY and > > I'm wondering if there is a better way to go…maybe appending the > > date format required to the message when it gets sent into the > > parser. > > >> > > >> Any help will be most appreciated as I'm a bit stumped on > > the preferred method for problems like this. > > >> > > >> Regards, > > >> > > >> Jeremy Nevill > > >> www.nevill.net <http://www.nevill.net> > > >> > > > > > > >
