You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the extractor provides a regular IonReader to callback invocations. This leads to the possibility that users can advance the reader during the callback without the extractor's knowledge. If the reader is advanced past a path that would have matched, the user will not receive that match. The documentation warns against doing this.
We may be able to support this by creating an internal implementation of the IonReader interface that contains a reference to the path extractor and the underlying IonReader. The implementation would intercept the IonReader API calls from the user, giving the path extractor the opportunity to evaluate for matches and fire additional callbacks.
It's possible there's some fatal flaw in this idea, as I haven't thought too deeply about it, but at a high-level it seems feasible.
The text was updated successfully, but these errors were encountered:
Currently, the extractor provides a regular
IonReader
to callback invocations. This leads to the possibility that users can advance the reader during the callback without the extractor's knowledge. If the reader is advanced past a path that would have matched, the user will not receive that match. The documentation warns against doing this.We may be able to support this by creating an internal implementation of the
IonReader
interface that contains a reference to the path extractor and the underlyingIonReader
. The implementation would intercept theIonReader
API calls from the user, giving the path extractor the opportunity to evaluate for matches and fire additional callbacks.It's possible there's some fatal flaw in this idea, as I haven't thought too deeply about it, but at a high-level it seems feasible.
The text was updated successfully, but these errors were encountered: