On 19 May 2015, at 17:13, Daniel Fuchs <[email protected]> wrote:
> On 19/05/15 12:07, Paul Sandoz wrote:
>>> Should anything be said also about default remove() method inherited from
>>> Iterator interface? Are custom asIterator() implementations allowed to
>>> return an Iterator that implements remove() in a way that actually removes
>>> elements?
>>> >
>> Since this method transfers control it seems a little mean to place such a
>> restriction on the returned Iterator. Although, there is no clear means of
>> stating to the caller whether such an iterator supports removal or not, but
>> that seems to be generally the case for any Iterator returning method.
+ * @implSpec
+ * The returned Iterator's {@link Iterator#hasNext hasNext} method calls
and returns
+ * the value from this Enumeration's {@code hasMoreElements} method; its
+ * {@link Iterator#next next} method calls and returns the value from this
Enumeration's
+ * {@code nextElement} method; and its {@link Iterator#remove remove}
method throws
+ * {@code UnsupportedOperationException}.
+ *
Why not turn the proposed implSpec into an implNote, and leave it up to other
API’s returning Enumerations to specify their behaviour of asIterator, if they
override the default.
-Chris.
>
> Ah... Interesting use case. I hadn't thought of that.
>
> What should ConcurrentHashMap.keys().asIterator().remove() do?
>
> cheers,
>
> -- daniel
