A better name for reducible! perhaps?

[seancorfield]

Per @ghadishayban on Slack:

reducible! is also a terrible name, while we're at it (edited)
reducible <Action> <----what's the action? I have a hard time with this one

This issue is a placeholder for discussion about possible better names.

[lensgolda]

Maybe prune! or shrink!...?

[seancorfield]

@lensgolda Those are even less descriptive than reducible! for what it does.

[lensgolda]

agree... so why it should has better name? I don't think reducible not enough descriptive, and such terrible name as mentioned in slack above...Sorry, maybe i didn't understand reasons for that.

[seancorfield]

Well, I happen to agree with you. It produces a "reducible" thing. That's why I named it reducible!. But if some folks think it's a terrible name, I'm happy to take feedback on better names while the library is in the alpha state. The equivalent in clojure.java.jdbc is reducible-query (because it only works for queries) but it's long and ugly so I wanted something shorter/simpler.

[lilactown]

I sometimes like as-x to note that I am returning a thing with some specific behavior / protocol / etc., so e.g. as-reducible. It feels like bikeshedding though.

[andharris]

executable!?

Reading the description in the REAMDE

• reducible! -- yields an IReduceInit that, when reduced, executes the SQL statement and then reduces over the ResultSet with as little overhead as possible.

It seems like this is creating something that makes the SQL executable when it's reduced.

To me this makes sense in relation to execute! that realizes the SQL ResultSet immediately.

[ghadishayban]

(->>
  (jdbc/plan (ds) ["select * from fruit where appearance = ?" "red"])
  (into []))

May I suggest plan? It has the desired connotation that it's not immediately doing anything, and doesn't overload prepare (as in prepared statement)

[seancorfield]

Thanks, @ghadishayban -- I like that.

I plan to move to Beta 1 "soon" and will make this change at that point -- and then no more breaking changes or renaming, from that point on.

I have been thinking about the group/artifact ID and the namespace names too but at this point, I'm pretty sure I'm going to stick with seancorfield/next.jdbc for the coordinates and next.jdbc.* for the namespaces. Given that I want to avoid clojure or any variant of that, since this is almost certainly not going into Contrib at this point, and I don't want my name in the namespace names, I'm fine with the current schema...

[seancorfield]

Closing as Beta 1 is in preparation.