Working with immutable collections

[Gernot Neppert]

Nice to hear that it's being considered!

 > LinkedList implements List and Queue, so when you try to inherit 
unmodifiable() from both List (returns List) and Queue (returns Queue), 
you have to override it with something that returns both a List and a Queue.

...and the top candidate for that "something" would be LinkedList, 
wouldnt' it?

 > Unfortunately this means reimplementing Unmodifiable for ad-hoc 
intersections like List&Queue.

OK, I get what you mean, but wouldn't this only prevent you from 
implementing both List and Queue in an anonymous manner?
Otherwise, similiar to LinkedList, you'd simply have to return the 
implementing class type from such methods.


Am 19.11.2012 16:54, schrieb Brian Goetz:
> That's on the list.  (Similar for synchronized()).
>
> Unfortunately, it's trickier than it looks, because of inheritance 
> diamonds.  LinkedList implements List and Queue, so when you try to 
> inherit unmodifiable() from both List (returns List) and Queue 
> (returns Queue), you have to override it with something that returns 
> both a List and a Queue.  Unfortunately this means reimplementing 
> Unmodifiable for ad-hoc intersections like List&Queue.  We can work 
> around this one by leaving List in the cold, but we still find 
> landmines.  For example, there's a stupid class in the JDK that 
> implements both List and Set (for bad reasons) and that happens to be 
> serializable so we can't even fix it easily.  Having the same problem 
> with List and Set is particularly annoying because you cannot 
> simultaneously implement the contract of List and Set!  But that 
> didn't stop whoever wrote this class.
>
> So what sounds like a no-brainer is actually more work than it looks.
>
> On 11/19/2012 10:07 AM, Gernot Neppert wrote:
>> I'd rather have an "unmodifiable" member function in
>> java.util.Collection, together with a "synchronized" function, something
>> like this:
>>
>> public interface Collection<E> {
>>
>> /**
>>     Returns an unmodifiable view of this Collection.
>>     @return an unmodifiable view of this Collection (may be {@code this}
>> instance if is already unmodifiable).
>> public Collection<E> unmodifiable() default {
>>         return Collections.unmodifiableCollection(this);
>>       }
>>
>> /**
>>     Returns a synchronized view of this Collection.
>> @param lock the Lock to use.
>>     @return a view of this Collection that executes all operations while
>> holding a Lock. (may be {@code this} instance if is already synchronized
>> on the supplied Lock).
>> @throws IllegalArgumentException if this Collection is already
>> synchronized on a different Lock.
>> public Collection<E> synchronize(Lock lock) default {
>>         return Collections.synchronize(this, lock);
>>       }
>>
>> }
>>
>>
>> These should of course be co-variantly overriden in java.util.List,
>> java.util.Set etc.!
>>
>>
>>
>>
>>
>>
>> Am 19.11.2012 15:39, schrieb Johan Haleby:
>>> Hi,
>>>
>>> I'm sorry if this has been discussed before but here goes:
>>>
>>> Let's say I have an immutable list called "xList" that I want to 
>>> filter and
>>> return the result as a new *immutable* list. I could do something 
>>> like this:
>>>
>>> Collections.unmodifiableList(xList.filter(obj -> 
>>> obj.something()).into(new
>>> ArrayList<X>())));
>>>
>>> How ever I think this is quite verbose and doesn't follow the fluent 
>>> style
>>> of the API. What I would like to have is something a long these lines:
>>>
>>> xList.filter(obj -> obj.something()).intoImmutable(new 
>>> ArrayList<X>()));
>>>
>>> "intoImmutable" could then do "Collections.unmodifiableList(..)" for 
>>> me so
>>> I don't need to wrap all statements where I want to return an immutable
>>> collection.
>>>
>>> What are your thoughts on this?
>>>
>>> Regards,
>>> /Johan
>>>
>>
>>