Let's please rename Block to Receiver before it's too late (original) (raw)
Doug Lea dl at cs.oswego.edu
Sat Jan 19 05:19:26 PST 2013
- Previous message: Let's please rename Block to Receiver before it's too late
- Next message: Let's please rename Block to Receiver before it's too late
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 01/18/13 21:36, Brian Goetz wrote:
OK, OK, if people really, really hate Block, I would still consider Sink. Sink is the opposite of Source. We could rename Supplier to Source, and rename Block to Sink. Leaving the method names the same (accept and get.)
"Sink" is nice in the Stream framework, which is a plus in encouraging people to use it, but not in other common contexts where the main property to convey is that it is a possibly side-effecting action, as opposed to a Function.
Does everyone else prefer "Action" as best possible name? If so, would we be willing to reconsider rejecting it because of Swing conflicts? The interactions do not seem to be all that bad: Swing programmers would never encounter problems as pure lambda-users (they need not import java.util.functions.Action or otherwise use the type.) So the only ones impacted are those who write lambda-accepting Swing methods, which do not yet exist.
And to help a bit further, we could keep the method name as "accept", to reduce conceptual conflict with the conventions surrounding "perform" in Swing.
interface Action { void accept(T t); }
-Doug
- Previous message: Let's please rename Block to Receiver before it's too late
- Next message: Let's please rename Block to Receiver before it's too late
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-observers mailing list