Expected distribution of lambda sizes (Re: Syntax poll, take 2)

[Sam Pullara]

We aren't changing it. No suggestion was made to change it. The suggestion was to include the null guards in the lambdas to make them more realistic as people have them in their normal java code.

Sam

On Jun 14, 2011, at 11:43 PM, Knox, Liam wrote:

> I do not know either.
>  
> Ok you have o.getName().  Please clarify how does that change in the context of lambda's and NPE's as was originally proposed at the start of this thread?
> If I pass some logic to a lambda or method call and it generates a NPE, fantastic. No extra Magic to regard.
>  
> Syntax aside, Consitent behaviour vs. the current model is Mandatoty. 
>  
> Personally I suggested o.getName() etc as it is what we use everyday.  Why change it?
>  
> From: Sam Pullara [mailto:spullara at gmail.com] On Behalf Of Sam Pullara
> Sent: Wednesday, June 15, 2011 3:33 PM
> To: Knox, Liam (PTT)
> Cc: Neal Gafter; lambda-dev
> Subject: Re: Expected distribution of lambda sizes (Re: Syntax poll, take 2)
> 
> I'm not sure how this got out on this tangent. I interpreted his post as saying that we should look at longer Lambdas rather than short ones since Java code will typically be a little more verbose than the examples that Brian had in his message.  
> t  
> Sam
> 
> On Jun 14, 2011, at 11:30 PM, Knox, Liam wrote:
> 
>> Ok. So are we saying basically the Closure proposal is not just to implementing a function that you can pass into a method, it is something more profound?
>> It changes how we consider null in a collection? 
>>  
>> Personally I write Java, because a) there are Jobs b) the language is fantastic and the evolution has been sound and managed well.
>>  
>> If you are saying my comparison on current and expected behavior is unsound may be I should jump on the Scala band wagon ahead of time.
>> I have had enough headaches with behavioral differences in HashMap vs. ConcurrentHashMap to not even want to experience more ambiguity. And certainly none at a fundamental level
>>  
>> From: Sam Pullara [mailto:spullara at gmail.com] On Behalf Of Sam Pullara
>> Sent: Wednesday, June 15, 2011 3:12 PM
>> To: Knox, Liam (PTT)
>> Cc: Neal Gafter; lambda-dev
>> Subject: Re: Expected distribution of lambda sizes (Re: Syntax poll, take 2)
>> 
>> He is saying that Java code is more complicated because of these types of issues and will sometimes be longer than the equivalent code in a language that doesn't need these guards.
>> 
>> Sam
>>    
>> On Jun 14, 2011, at 11:09 PM, Knox, Liam wrote:
>> 
>>> So we agree.
>>>  
>>> We have a limbo language. With a boolean that can mean more than just true or false !
>>>  
>>> My point is if I pass a Function (i.e. Google collections like) to a method, and that then throws a NPE, all is well.
>>> This is what I want to happen and expect and can handle.
>>>  
>>> Are you saying semantically Closures should behave differently ?
>>>  
>>> From: neal.gafter at gmail.com [mailto:neal.gafter at gmail.com] On Behalf Of Neal Gafter
>>> Sent: Wednesday, June 15, 2011 3:00 PM
>>> To: Knox, Liam (PTT)
>>> Cc: Sam Pullara; lambda-dev
>>> Subject: Re: Expected distribution of lambda sizes (Re: Syntax poll, take 2)
>>> 
>>> On Tue, Jun 14, 2011 at 10:54 PM, Knox, Liam <Liam.Knox at morganstanleymufg.com> wrote:
>>> Boolean a = null; 
>>>  
>>> if(a){}
>>>  
>>> What does that do ?
>>> 
>>> It throws a NullPointerException [sic].
>>> 
>>>  
>>> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.
>> 
>> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.
> 
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.