Function type naming conventions

[Kevin Bourrillion]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130124/015c1dc5/attachment.html