Function type naming conventions (original) (raw)

Kevin Bourrillion kevinb at google.com
Thu Jan 24 14:45:22 PST 2013

Yeah, I'm fine with that too. Does that make it generally true that we always omit Bi when it's clearly implied?

On Thu, Jan 24, 2013 at 2:20 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

+1 ObjIntBlock (or a more descriptive "Block" name if one is selected)

On Thu, Jan 24, 2013 at 2:16 PM, Brian Goetz <brian.goetz at oracle.com>wrote: OK, I've completed: - {Int,Long,Double}Function -> ToXxxFunction - {Int,Long,Double}BiFunction -> ToXxxBiFunction - Obj{Int,Long,Double}Function -> XxxFunction The remaining weird ones are: ObjIntBiBlock (T, int) -> void These could stay ObjIntBiBlock, or, with the "arity unnecessary if all args are specialized" rule tweak, could become: ObjIntBlock Thoughts?

On 1/24/2013 2:03 PM, Joe Bowbeer wrote: On Thu, Jan 24, 2013 at 10:52 AM, Dan Smith <daniel.smith at oracle.com_ _<mailto:daniel.smith at oracle.**com <daniel.smith at oracle.com>>> wrote: Let me propose a slightly different convention: if the base type is parameterized in both its parameters and return, then the "To" prefix is mandatory. If not, "To" is not used.

This works for me if the base name is descriptive enough. IntSupplier, IntConsumer, even IntBlock (now that I know what a Block is). —Dan

-- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com

More information about the lambda-libs-spec-observers mailing list