-execute is plan so it should return an IReduceInit -- it should not get a connection immediately.

The implementations are all standalone. Partly for performance but partly for maintenance -- having the code inline means that if I'm considering the three implementations for a single protocol, I have all the code right there on a single screen and I don't have to drill into some other definition to think through the code.

Though the extend-protocol p/Executable has impl. for both D.S. and Connection at the same place so if one reused the other you still would only need to scroll up a few lines?

Each set of implementations is about one screenful of code so it would end up being more than "scroll[ing] up a few lines". And performance matters (I went back and forth a lot with Tommi Reiman while next.jdbc was being developed).

Thank you!

That's why runtime testing of types/protocols is off the table, BTW, for performance-critical functions (`execute-batch!` is not considered p/c there because the batched DB activity is assumed to completely overwhelm the cost of calling it and you don't tend to call it repeatedly: you call it "once" with large batches of data -- but execute! etc are p/c).

(and I really don't want to extend those protocols to Object!)

I understand