On 20/05/15 08:20, Paul Sandoz wrote:
On May 19, 2015, at 6:19 PM, Chris Hegarty <chris.hega...@oracle.com> wrote:
On 19 May 2015, at 17:13, Daniel Fuchs <daniel.fu...@oracle.com> 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.
The @implSpec section is specifying the behaviour of the default implementation. Usually
we prefix with "The default implementation ...".
D'oh, I mixed up @implSpec and @implNote (again). What Stuart has
already cover this.
-Chris.
Paul.
