Exposing the lexer/parser about goxpath HOT 6 CLOSED

I can see why one would want access to the lexer, but you sure you want access to the parser? The parse tree is built in a very particular way so the evaluator can do its job, and if goxpath's evaluator isn't behaving the way you want, building another evaluator around goxpath's parse tree probably won't do you any good.

Also, can you explain where you're seeing some performance issues in goxpath?

from goxpath.

The performance issues are because I don't evaluate it on XML exactly, so most of the functions in findUtils are really expensive. On the other hand, I can take some shortcuts that aren't available in XML.

The parse tree is built in a very particular way so the evaluator can do its job, and if goxpath's evaluator isn't behaving the way you want, building another evaluator around goxpath's parse tree probably won't do you any good.

Until now I haven't faced anything like this, benchmarks are looking quite good. It sounds like there is something specific you have in mind wrt any design decisions in the evaluator though, which I might not have hit yet.

from goxpath.

Can you point to which parts in the lexer/parser packages you need? It's probably not as simple as just getting rid of the internal part; a lot of methods and fields are private because they weren't really designed with a public API in mind.

from goxpath.

For now, I'm using pretty much everything the current evaluator is using, only in a different way. You can have a look at the changes i've made at https://github.com/aristanetworks/goxpath/commits/master

from goxpath.

Your changes look good. Pulling them down.

from goxpath.

excellent, thanks a lot!

from goxpath.