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
this definition works:
An effectively immutable object is an object where its fields are:
* final primitives or strings
* primitives or strings without the ability to change their values (so
effectively final like with lambdas)
* a final or effectively final object made up effectively immutable fields
I'm not sure how to fit arrays in there since you can only have an
effectively final array as the components themselves can't be marked final.
Another way to look at it is like this:
Objects are effectively immutable if a.equals(a) for the entire lifetime of
a.
The first definition gives a nice way to look at implementations while the
second definition gives the end result of what guarantee we'd need here.
On 26 March 2017 at 00:27, Gary Gregory <garydgreg...@gmail.com> wrote:
> On Fri, Mar 3, 2017 at 8:05 AM, Matt Sicker <boa...@gmail.com> 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 specializing for
> primitives or known JRE immutables like String and Integer? Curious...
>
> Gary
>
> 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
> > underlying objects would be nice.
> >
> > On 3 March 2017 at 09:58, Jörg Schaible <joerg.schai...@bpm-inspire.com>
> > wrote:
> >
> > > 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 immutable concerning the referenced objects, it
> > > cannot
> > > make any assumptions about those objects' immutability.
> > >
> > > StringBuilder builder = new StringBuilder();
> > > ImmutablePair<String, StringBuilder> = new ImmutablePair<>("key",
> > builder);
> > > builder.append("a");
> > >
> > > ImmutablePair just guarantees here that you will always have the same
> > > StringBuilder instance.
> > >
> > > Cheers,
> > > Jörg
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> > --
> > Matt Sicker <boa...@gmail.com>
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <boa...@gmail.com>
