> On Nov 29, 2021, at 10:42 AM, Simon Roberts <si...@dancingcloudservices.com> 
> wrote:
> 
> I will say that as Java provides more and more features modeled on more
> functional languages, I'm finding more and more people struggling with the
> inherently mutable nature of Java, and that I strongly believe that
> something that helps bridge the gap is likely to be crucial to the
> language's continued improvement and growth. Clearly it can't turn into
> Haskell, nor should it, but without saying what, may I add my voice to
> those looking for this kind of feature.
> 

I agree with this sentiment.

> One thing that I haven't seen discussed is the fact that Java has had the
> "const" keyword since the beginning, but it's never been implemented. That
> raises the question of whether it's more practical (in terms of bridging
> styles) for methods to guarantee that they don't change some object (i.e.
> implement const) or for a data type to be declared in a way that it cannot
> be mutated (i.e. the @Immutable discussion). Given the difficulties raised
> already in attempts to create truly immutable lists, or perhaps read-only
> lists, and merge them in the existing library APIs, perhaps it's worth
> considering attacking the problem from the other side? Perhaps there's a
> way to declare a particular reference as "only to be used with const /
> non-mutating operations". Might the combination of those two features be
> worth consideration?

I don’t see how a restricted reference by itself is useful, if you cannot 
depend upon the object not being mutated via other references.
Swift has solved this issue (as far as I can tell), but it has a fundamentally 
different semantics.

I think the solution is to abandon the goal of fully integrating immutable 
collections into the existing collections API.
Yes, that creates API bloat, but it may be worth it.
I’ve done that in my own programming and have no regrets.

There are precedents: NIO Paths vs Files, Streams vs Iterators, Modules vs 
Classpaths.
To be fair, I don’t use Paths or Streams or Modules, because the payoff seems 
small.
The payoff for immutable collections is much larger, in my opinion (less buggy 
code).

  Alan

Reply via email to