[Discussion] CtQuery Improvements

[bolu61]

I found that the API of CtQuery is somewhat limited. It functions essentially, as I understand it, similarly to a stream of CtElements, but is limited to consumption by CtConsumers and collection into lists. I came across the discussion in #1070 and the limitations are justified by the fact that the implementation is based on CtScanner. Is there a reason that CtScanner must be used?

Now that there is #1986, the following is possible:

Stream<CtElement> query = StreamSupport.stream(element.asIterable().spliterator(), false);

From what I understand, this can replace CtQuery. Can java stream replace the query API? If not what are the missing features or differing behaviours? Is it possible to reimplement/refactor CtQuery to use streams internally?

[slarse]

Hi @ananA2,

From what I understand, this can replace CtQuery. Can java stream replace the query API?

I haven't used CtQuery much myself, but I think that is the case. The CtQuery interface is something I don't think any of the Spoon integrators are too keen to keep expanding; it's better to just provide convenience functionality that delegate to proper Java streams.

Can java stream replace the query API? If not what are the missing features or differing behaviours?

From my limited exposure to this part of the code base, I would say streams can sufficiently replace the CtQuery interface.

Parts of the CtQuery interface relies on unsafe use of generics (e.g. having a generic method where the generic applies only to the return type), which can't be fully reproduced with regular Java streams. But that's not really desirable either, it's a design flaw of CtQuery.

Is it possible to reimplement/refactor CtQuery to use streams internally?

To some extent, yes. But I'm not confident the full functionality can be replicated without breaking changes to the API. But it's definitely worth looking into.

[bolu61]

Hi @slarse,

Thanks for your input.

it's better to just provide convenience functionality that delegate to proper Java streams.

There could be a proper implementation of spliterator, so that elements could then be processed by parallel streams.