Implicit 'this' return for void methods

[Peter Levart]

On 04/03/2014 09:54 AM, Bruce Chapman wrote:
> On 3/04/2014 6:01 p.m., Peter Levart wrote:
>> On 04/01/2014 11:28 AM, Bruce Chapman wrote:
>>> Slightly preceding Ulf's coin proposal by a few hours was
>>>
>>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html
>>>
>>> Where I suggested the "naked dot" notation (coined in 
>>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html) 
>>> has better value as ".. a
>>> syntax for referring to the receiver of a method inside arguments to 
>>> the
>>> method."
>>>
>>> More formally, the naked dot  (at the start of an expression, not 
>>> following an invocation to a void method) would refer to the 
>>> receiver of the innermost surrounding invocation expression.
>>
>> A: What is the receiver of the invocation of a static method?
>>
>> B: What is the receiver of the invocation of a constructor?
>
> Peter,
>
> I haven't checked the JLS formal terminology but in both cases it is 
> the class's static context, such that a naked dot could only precede 
> static methods and fields.
>
> Bruce

I'm asking about the meaning of the following (not very optimal) example:

     myVeryLongNamedString.substring(Math.min(.indexOf("A"), 
.indexOf("B")), Math.max(.indexOf("A"), .indexOf("B")));

You're suggesting that invocations of static methods don't count towards 
the innermost invocation, since they don't have a "receiver" therefore 
the search for innermost receiver skips them?

If so, then the following code:

     myVeryLongNamedString.substring(min(.indexOf("A"), .indexOf("B")), 
max(.indexOf("A"), .indexOf("B")));

could have two different meanings depending on whether unqualified min() 
and max() are invocation of static vs. instance methods. That's very 
hard to read then.


Regards, Peter

>
>>
>>
>> Regards, Peter
>>
>>
>>>
>>> and so to answer Guy's question below in terms of my original 
>>> intention rather than Ulf's proposal, .indexof("Q") would use 
>>> myVeryLongNamedString as its receiver.
>>>
>>> I see particular value for these naked dot expressions in creating 
>>> fluent APIs such as builder patterns. As suggested in my coin post, 
>>> there is also value for passing enums or named constants to methods 
>>> when (as is often the case) these named constants are defined in the 
>>> same class as the method being invoked. In a highly informal sense, 
>>> the naked dot enables on demand changing of the scope to be that of 
>>> the invocation expression's receiver,
>>>
>>> I think with this interpretation of the meaning of naked or leading 
>>> dot, Guy's compromise restriction below is not required.
>>>
>>> Bruce
>>>
>>>
>>> On 27/03/2014 4:51 a.m., Guy Steele wrote:
>>>>
>>>> I am a bit more skeptical about expressions that begin with a dot 
>>>> because of potential
>>>> confusion about which expression is referred to:
>>>>
>>>>      myVeryLongNamedString.subString(.indexOf("C”), .indexOf("Q”))
>>>>
>>>> seems clear enough, but what about:
>>>>
>>>>      myVeryLongNamedString.subString(.indexOf("C”) + 
>>>> otherString.length(), .indexOf("Q”))
>>>>
>>>> Does the second occurrence of .indexOf use myVeryLongNamedString or 
>>>> otherString?
>>>>
>>>> A compromise would be to allow leading-dot expressions to occur 
>>>> only within the arguments
>>>> of the method call whose target is the object which the leading-dot 
>>>> expressions are expected
>>>> to use as their target, and if there are such leading-dot 
>>>> expressions within the arguments
>>>> then the arguments must not contain any non-leading-dot field 
>>>> references or method calls.
>>>> Just a thought for discussion.  This would be considered a separate 
>>>> mechanism from the
>>>> chaining-of-void-methods mechanism (it was a very clever idea to 
>>>> try to unify them in Ulf's
>>>> original proposal, though).
>>>>
>>>> —Guy
>>>>
>>>>
>>>
>>>
>>> ---
>>> This email is free from viruses and malware because avast! Antivirus 
>>> protection is active.
>>> http://www.avast.com
>>>
>>>
>>
>>
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus 
> protection is active.
> http://www.avast.com
>