On Wed, Jul 25, 2012 at 07:47:34AM +0200, Kaspar Schiess wrote: > > Nice to see you're working on that part again!
Yes, happily upgrading my stuff to a pristine Parslet 1.4.0. No surprises so far. > > I was wondering if such a patch would make sense: > > > > > > https://github.com/jmettraux/parslet/commit/d01ed604d158498635924ed1063f7fc27837ce81 > > > > […] > > which would match nicely with the #deepest(given) returning the > > deepest_cause > > instead of the given cause. > > I've taken a quick peek at what you propose. If I understand you right, you'd > like the deepest single error without its lineage. > > I've tried to conserve that exact lineage with my code. The logic was that it > is easy to extend Cause with a method that extracts the deepest single error > from that, but the inverse cannot be done. Somehow, I need to present a helpful error message to my users, the cause lineage is only important to me while developing the grammar. > I would certainly accept a nicely written 'deepest_child' method on Cause as > a patch! And a delegate on the exception maybe? Your code would look like > this: > > begin > parser.parse(s) > rescue Parslet::ParseFailed => ex > puts ex.deepest_cause > # or > puts ex.cause.deepest_child > end > > I feel having this as an option opens up the possibilities for others, > instead of giving them just what we think they need. It encourages > experimentation, if you so will. > > Or .. you can always convince me of your initial patch, you're the inventor > of the method ;) I will go on hiding Parslet::ParseFailed from my users (and presenting them instead the deepest cause out of the reporter), that's a good compromise between my dev needs and their usage needs. Thanks for taking the time to look at that. Cheers, -- John Mettraux - http://lambda.io/jmettraux
