Considering the limitations in syntax available for this (compare to Rust
which makes things immutable by default and requires a "mut" modifier to
change things), I think it'd have to be documented that this sort of pair
would only work with objects that were effectively immutable. Let's see how
th
On Fri, Mar 3, 2017 at 8:05 AM, Matt Sicker wrote:
> So would a further specialization be useful here for an immutable pair of
> immutable objects?
Hi Matt,
But how would you guarantee that aside from using a marker interface to
denote an object as being immutable? Are you talking about speci
So would a further specialization be useful here for an immutable pair of
immutable objects? In my own applications, I tend to embrace immutability
everywhere (except for certain performance-intensive areas involving byte
buffers and encoding/decoding), so being able to make assumptions about the
u
Hi Matt,
Matt Sicker wrote:
> I took a look at this yesterday and forgot to reply. Anyways, I agree that
> ImmutablePair should override compareTo() since it can rely on its own
> values not changing, whereas the implementation in Pair isn't as crazy
> since it's mutable.
ImmutablePair is only i
I took a look at this yesterday and forgot to reply. Anyways, I agree that
ImmutablePair should override compareTo() since it can rely on its own
values not changing, whereas the implementation in Pair isn't as crazy
since it's mutable.
On 2 March 2017 at 15:55, Gary Gregory wrote:
> I was going
I was going to replace my custom pair class with ImmutablePair but it looks
like the compareTo() methods in the superclass creates a LOT of objects on
each call. Any thoughts on a custom implementation that would not create to
much garbage to collect?
--
E-Mail: garydgreg...@gmail.com | ggreg...@
