Static state in SPI could lead to staleness issues

[ZacSweers]

If you have a TypeProcessor that does stateful things, you could run into issues with that state remaining. Not sure if the static approach was intentional, but just mentioning.

[benjamin-bader]

Very true! I never considered stateful processors.

What do you have in mind?

[benjamin-bader]

It might be worthwhile to look at alternatives to the simple SPI model we've been using. Internally we've butted up against its limitations in a few ways:

• not possible to have more than one processor, so the ones we use end up becoming quite complicated
• the one-type-at-a-time model is nice for streaming, but in practice we often want to look at other generated type definitions at the same time.

Both problems are solvable, of course - just takes some thought beforehand.

[ZacSweers]

Selfpromotion, but could look at Crumb :)

[ZacSweers]

Also just saw your previous comment - what we do internally is processors are reused across modules (so we have a warm JIT cache. Buck build optimizations and whatnot). So when we invoke the lookup, we just look them up again for the current classpath

[benjamin-bader]

(testing whether I still have maintainer access by closing an old issue and re-opening it. sorry zac)