oSumAtrIX

A small optimization can be done which is late initializing the cache until a fingerprint needs it. Right now, the cache is lazy but the mergeExtensions function accesses it prematurely...

> They should not be a giant lambda of logic (with more embedded lambdas). You dont have to use lamdbas. You can access fields directly via . or write an...

To clarify, my stance here is still very strong in favor of this API. I am telling you this to give you an insight of how strong your arguments should...

The last thing left is to construct the matcher out of scope. The API already allows it but its not elegant to write a val everytime like this: Any scope...

Okay this was a tough one. Basically: The first* functions had no instance. The nearest receiver instance was BytecodePatchContext. However saving state there was not viable because the first* functions...

The only alternative I think would be to use the builder pattern somehow. Each call would build a final object. During building the various elements could be placed in suitable...

Right now the APIs are consistent with Kotlin. E.g. firstMethod is internally calling methods.first { predicate }. I was thinking of the by convention such as associateBy: methodBy { name...

So a regression/difference to fingerprints is finding the indices of instructions during fingerprinting. The matchers can support this and I'll also include an example implementation, but I dont know if...

> You wrongly criticize using custom instruction filters as "punching a hole in the API" (instruction filter is the API!) It is a correct criticism. Using a custom block goes...

This, functionally supersedes the other PR to act as a temporary compatibility to the patches PR I was thinking of adding an "space(size=,optional=)" but after is probably good the way...