This is a draft of changes I would like to make in order to add an API to iterate through results in a more "ergonomic" way. Due to the constraints of the iterator not actually producing elements, I could not implement Iterator<Item = SomeResult> for the elements of the iterator (unless I'm missing something obvious this would have to be done with a streaming iterator) but I settled on a strongly typed next() function that produces a strongly typed result.
I'm not entirely a fan of this interface, and there are unresolved questions about what bounds should look like wrt things like getting all textlines in a single block, or getting all characters in a textline or what have you, but I figured this was good enough for at least a look.
In making some of these changes, I also migrated the integration tests to tests/ over having them be in-file. I'm fine with moving it back in the file, but feel that doctests or similar are more deserving of being in-file.
The result types are strongly typed, and I have some more prototyping to do around getting textlines in a block type thing but those are less design-type issues.
This is a draft of changes I would like to make in order to add an API to iterate through results in a more "ergonomic" way. Due to the constraints of the iterator not actually producing elements, I could not implement
Iterator<Item = SomeResult>for the elements of the iterator (unless I'm missing something obvious this would have to be done with a streaming iterator) but I settled on a strongly typednext()function that produces a strongly typed result.I'm not entirely a fan of this interface, and there are unresolved questions about what bounds should look like wrt things like getting all textlines in a single block, or getting all characters in a textline or what have you, but I figured this was good enough for at least a look.
In making some of these changes, I also migrated the integration tests to
tests/over having them be in-file. I'm fine with moving it back in the file, but feel that doctests or similar are more deserving of being in-file.The result types are strongly typed, and I have some more prototyping to do around getting textlines in a block type thing but those are less design-type issues.