brian.goetz at oracle.com
Fri Sep 21 09:25:52 PDT 2012
I think the "if we don't support it people won't adopt lambda" is way,
way overstated. Its a factor to consider, nothing more.
But, the reality is that code where there are nulls in collections is
still likely to blow *somewhere*. Yes, it would be great if it blew
where the null was inserted. But that ship has sailed. What we're
discussing now is:
- should we check nulls when the element flows into the stream?
- should we check nulls at the other end, like forEach/into/toArray?
- should we stick our fingers in our ears and say "la la la can't see
those nulls la la la"?
On 9/21/2012 12:11 PM, Remi Forax wrote:
> On 09/21/2012 05:37 PM, Kevin Bourrillion wrote:
>> On Fri, Sep 21, 2012 at 5:49 AM, Remi Forax <forax at univ-mlv.fr
>> <mailto:forax at univ-mlv.fr>> wrote:
>> Support them is the only realistic option, there are too many
>> codes out there that put null in collections, otherwise it will
>> seriously impede the adoption of lambdas.
>> You would think so, but take a look at how hard Guava is on nulls, and
>> we pretty much get away with it.
>> There are always plenty of strategies for fixing your code to not need
>> to put nulls into collections, and most of them leave the code better
> Let's say that streams will not support nulls.
> My fear is that if a collection have a null in it, it will blow in the
> middle of the process,
> far away from where the error lies i.e. when null was added in the
> To reuse the Josh moto, blow often, blow early, if you don't throw the
> exception early,
> at the point where the mistake is made, throwing an exception in the
> middle of the process
> will be seen as something annoying instead as something that heps devs.
>> I'm not taking a position on the issue, just saying the argument that
>> we /have/ to support nulls doesn't hold water with me. So /what/ if it
>> "impedes adoption" of lambdas a bit? Pleasing everyone all of the time
>> isn't an option anyway.
More information about the lambda-libs-spec-observers