Thanks again for the help and examples. As it wasn't easy to view my source on the original question I have extracted the Shortee Parser into it's own gem with a number of specs:
https://github.com/JeremyNevill/shortee So I'm now back trying to solve my initial problem which is looking a bit trickier the more I investigate time zones/time parsers within ruby and rails. Here is my problem restated: A US based user adds a Short using their local date format: e.g. '@frank drove 20miles 11/05/2013' A UK based user adds a Short using their local date format: '@james consumed 3pints 05/11/2013' Based on the location of the user the rails app parses the messages and dates using the correct methods. What I'm having difficulty working out is how to use the timezone information that I can get from rails to affect how I parse the date section of my message. Would you guys recommend: 1) parsing the majority of the message using parslet, then handing off the date part as a string to a specialised timezone aware date parser 2) parsing the whole message in parslet, passing in a custom date parser based on the user's time zone 3) parsing the whole message in parslet, passing in the user's time zone, using a simplified date parser that I write 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> > > >> > > > > > > >
