hg: lambda/lambda/jdk: Modify Iterables.uniqueElements to be fully lazy.

[Rémi Forax]

On 05/02/2012 11:28 PM, Stuart Marks wrote:
> On 4/13/12 4:12 PM, Rémi Forax wrote:
>> On 04/14/2012 12:23 AM, stuart.marks at oracle.com wrote:
>>> Changeset: 08c12c22393c
>>> Author:    smarks
>>> Date:      2012-04-13 15:24 -0700
>>> URL:       
>>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/08c12c22393c
>>>
>>> Modify Iterables.uniqueElements to be fully lazy.
>>
>> Hi Stuart,
>> null should be an allowed value.
>> It's really easy to implement it with a null object.
>> Also I think it's better to let the user choose which Set he wants to 
>> use
>> (the equals semantics is not always the best).
>>
>> So the code should be something like this: [...]
>
> Hi, finally getting back to this.
>
> From Brian's other notes you might have gathered that we're generally 
> leaning against supporting null values. But it's good to know that 
> using the null object technique can be used to implement it if we 
> choose to do so.

and I feel it's a really bad idea to not support null.
I mean we should just propagate the null not do more, not do less.

If we don't support null, people can't replace their old code in a 
library by a code that use lambdas
without introducing backward compatibility issue so no refactoring, no 
way to simplify the code
to make it readable.

>
> Good point also about allowing the caller to choose a different set 
> implementation. The most obvious alternative would be IdentityHashSet 
> which -- doh! -- doesn't exist in the JDK, but which has been 
> implemented elsewhere several times.

It exists but you have to cast the spell correctly :)
Collections.newSetFromMap(new IdentityHashMap<String, Boolean>());

> Mike Duigou also pointed out that if the stream is known to be sorted, 
> maintaining a set isn't necessary at all.

I'm not a big fan of attributes that internally say if the stream is 
sorted or not.
It's not in the spirit of the actual collection API. Collection and Set have
the same external interface (in OO way) but are two different interfaces 
and not
an interface with a flag that says if the Collection is a set or not.

> Another alternative is to have the caller pass in a Factory instead of 
> an instance.

Yes, this is basically what Scala does.

>
> I'll add this to our issues list but I don't think I'll proceed with 
> this at the moment.
>
> s'marks
>

cheers,
Rémi