Using the Index<str> trait to implement the awesome path based querying support doesn't make a lot of sense to me.
I'm proposing that we:
move the index<'str> code into it's own method(s), and
Edit, I'm going to make pushing this into a separate module a future problem for now,
2. possibly move it into it's own module within this crate.
~~JsonPath and others keep the selector/query logic separate from the data they're working on, and I like the fact that would keep the logic and tests separate, as I think there's going to have to be a lot of tests/docs to go with this. ~~
I think I like the naming of creating a Selector, which can be used to query() or query_path a Message/segment etc but am option to better options.
Using the
Index<str>
trait to implement the awesome path based querying support doesn't make a lot of sense to me.I'm proposing that we:
Edit, I'm going to make pushing this into a separate module a future problem for now,
2. possibly move it into it's own module within this crate.~~JsonPath and others keep the selector/query logic separate from the data they're working on, and I like the fact that would keep the logic and tests separate, as I think there's going to have to be a lot of tests/docs to go with this. ~~
I think I like the naming of creating aSelector
, which can be used toquery()
orquery_path
a Message/segment etc but am option to better options.