Hi Stuart,
I'm cautious about doing work piecemeal toward immutable collections.
The current unmodifiable approach only gives partial protection to the
caller
and none to the callee. The assertions it makes are too weak to be useful.
I think more value can be achieved by creating concrete final immutable
collections
that applications can use to be certain that the semantics of the collection
are immutable. They can implement the current interfaces but would be
compile time
knowable of the complete semantics of mutability. Then a good bridge
between
the current streams (and collections) would be methods that return the
concrete final collections.
BTW, I don't think many people are confused by 'immutable' collections
appearing
to be mutated because one of the objects in the collection is mutable.
Thanks, Roger
On 9/21/2017 2:55 PM, Stuart Marks wrote:
On 9/21/17 5:42 AM, Alan Bateman wrote:
On 21/09/2017 01:02, Stuart Marks wrote:
http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.0/
I read through the updated/new definitions and they read well.
Great.
For the copyOf methods then I can't immediately tell from the javadoc
if the
given collection can contain null elements. Taking List.copyOf as an
example
where coll may be null or it may contain null elements. The javadoc
does link to
"Unmodifiable lists" where it specifies the characteristics of the lists
returned by the static factory methods - these include disallowing null
elements. So I think this needs to be clarified.
Agreed, I'll work on some clarifications here, and also disallow null
for the argument itself.
Minimal implementation is okay to get started but what is the reason
not to
include some basic tests?
Sorry, I should have been more clear about this. The changeset is
clearly not ready to go in as it stands. I wanted to get an initial
review of the specifications going, then file a CSR request, etc.
while continuing to work on tests and better implementations. I'll
post a subsequent review when they're ready.
Thanks.
s'marks
