Hi Stuart,
On 9/22/2017 4:37 PM, Stuart Marks wrote:
On 9/22/17 5:36 AM, Roger Riggs wrote:
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'm not entirely sure what you're driving at here. Looking at this
again, I can see at least one place that should be strengthened. In
List.copyOf, something like this should be added:
Any modifications to the given Collection are not reflected in the
returned List.
(And similar for Set.copyOf and Map.copyOf.)
Are there other assertions that should be added or strengthened?
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.
It would add some value to have concrete, "immutable" collection
classes exposed. Presumably though these would implement the
List/Set/Map interfaces. As instances get passed around, the
"immutable" part would get "cast" away, limiting the value added.
What it enables, is writing a library or implementation in which the
immutable never gets cast away.
The concrete immutable types would be the *only* types used in the
interface to the library.
If desired a library might provide convenience functions that accept
loosely typed lists/maps/sets
and makes copies to effect the assertions. Any objects returned would be
the concrete immutable
types and callers could rely upon the full semantics.
I'm suggesting caution now, because if such immutable types become part
of SE then the
new methods you are adding should be returning the concrete immutable types
and not the current interfaces with no assertions about immutability.
Adding additional methods
with similar names later to return immutable instances will be redundant
and create their own kind of
confusion.
Roger
