Hello

As I said before I know the solution is not the best one, and an 
interceptor that can apply to all parsers could me much better. I might 
try an implementation with Parser.run when I find some free time. At 
least I will do it next time I have to implement a new parser.

I don't see how this feature could be doable without framework change. 
How can you get the index and the module without accessing to 
ParseContext ? This implies creating an subclass of Parser, that is not 
possible outside of the framework. My initial implementation of 
LocatableParser was outside of the core framework, but I had to change 
the visibility of some classes and methods.

Sylvain

Le 01/07/13 18:56, fluentfuture a écrit :
>
> In src/main/java/org/codehaus/jparsec/LocatableParser2.java:
>
> > +	  private final Parser<T> parser;
> > +	  private LocatableHandler<U> handler;
> > +
> > +	  public LocatableParser2(Parser<T> parser, LocatableHandler<U> handler) {
> > +	    this.parser = parser;
> > +	    this.handler = handler;
> > +	  }
> > +
> > +	  @SuppressWarnings("unchecked")
> > +	  @Override boolean apply(ParseContext ctxt) {
> > +	    int begin = ctxt.getIndex();
> > +	    if (!parser.apply(ctxt)) {
> > +	      return false;
> > +	    }
> > +
> > +	    handler.handle((U) ctxt.result, ctxt.source.subSequence(begin, ctxt.getIndex()).toString(), begin, ctxt.getIndex());
> I meant to give the interceptor idea a try but didn't manage to get 
> free time over the week end. If it's implementable, I like it better 
> because it's not restricted to source location. It can be used 
> probably to do other cool things that apply to not only one or two 
> single parsers but to *all* parsers. locate() is not bad, but it's 
> already doable without a core framework change: 
> Parser<LocationAware<T>> locate(Parser parser) { return 
> sequence(INDEX, parser, INDEX).map(…); } And it doesn't require 
> unchecked casting. The main issue with this kind of combinator is that 
> locate() call will proliferate in user's code base. Adding a core 
> combinator doesn't address this issue.
> … <#>
> On Jun 27, 2013, at 2:19 PM, Xikilze <notifications@github.com> wrote: 
> In src/main/java/org/codehaus/jparsec/LocatableParser2.java: > + 
> private final Parser<T> parser; > + private LocatableHandler<U> 
> handler; > + > + public LocatableParser2(Parser<T> parser, 
> LocatableHandler<U> handler) { > + this.parser = parser; > + 
> this.handler = handler; > + } > + > + @SuppressWarnings 
> <https://github.com/SuppressWarnings>("unchecked") > + @Override 
> <https://github.com/Override> boolean apply(ParseContext ctxt) { > + 
> int begin = ctxt.getIndex(); > + if (!parser.apply(ctxt)) { > + return 
> false; > + } > + > + handler.handle((U) ctxt.result, 
> ctxt.source.subSequence(begin, ctxt.getIndex()).toString(), begin, 
> ctxt.getIndex()); I say it is can be more difficult in the sense I 
> don't know if it is as simple as invoking an interceptor in 
> Parser.run. abailly's solution (which is very similar to the one I 
> implemented some time ago, that's why I submitted the little patch) 
> has the advantage of not being intrusive with the existing codebase : 
> combinating a new parser, isn't it the nature of JParsec ? If you fell 
> you can easily implement a far more elegant solution, then submit your 
> patch... — Reply to this email directly or view it on GitHub.
>
> —
> Reply to this email directly or view it on GitHub 
> <https://github.com/abailly/jparsec/pull/7/files#r4966394>.
>