On Jun 13 2013, at 14:56 , Remi Forax wrote:
> On 06/13/2013 04:47 PM, Paul Sandoz wrote:
>> On Jun 13, 2013, at 4:06 PM, Remi Forax <[email protected]> wrote:
>>>>> There is a difference between an Iterator/forEach and a
>>>>> spliterator/stream,
>>>>> with a stream you know that the called lambdas will not interfere and
>>>>> mutate the source collection.
>>>>>
>>>> You do? I don't think there is any conceptual difference between the
>>>> following w.r.t. interference:
>>>>
>>>> ArrayList l = ...
>>>> l.stream().filter(...).forEach(e -> l.add(e));
>>>> l.spliterator().forEachRemaining(e -> l.add(e));
>>>>
>>>> and:
>>>>
>>>> ArrayList l = ...
>>>> l.forEach(e -> l.add(e));
>>>> l.iterator().forEachRemaining(e -> l.add(e));
>>>>
>>>> Of course we have (or will have) strong wording saying don't implement
>>>> interfering lambdas, but we still have to check for co-modification in the
>>>> traversal methods of ArrayList spliterator.
>>> Isn't it because if you remove an element from an ArrayList while iterating
>>> you can see a stale value ?
>>> While with a HashMap, if you have only one thread, you can not see a stale
>>> entry ?
>> Assuming just one thread do you agree that in all of the above examples the
>> only way the list can be interfered with is by the Consumer instance e ->
>> l.add(s) ?
>
> yes, as I said to Mike, what is important IMO is that the semantics of
> forEach and the semantics of for(:) should be the same.
This seems like an undue restriction unless the order of elements in the entry
set is specified. Otherwise it implies a dependence upon an unspecified order.
To guarantee that forEach and for(:entrySet) will use the same unspecified
order seems an inappropriate. Would you tolerate:
* Performs the given action on each entry in this map until all entries
* have been processed or the action throws an {@code Exception}.
* Exceptions thrown by the action are relayed to the caller. The entries
* will be processed in entry set iterator order unless that order is
* unspecified in which case implementations may use an order which differs
* from the entry set iterator.
I really want to avoid tying the hands of future implementators. The most
frustrating specifications to conform to are those which were unnecessary or
poor judgement.
Mike
