ImmutablePair and compareTo()

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ImmutablePair and compareTo()

garydgregory
Reply | Threaded
Open this post in threaded view
|

Re: ImmutablePair and compareTo()

Matt Sicker
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 <[hidden email]> wrote:

> 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: [hidden email] | [hidden email]
> 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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: ImmutablePair and compareTo()

Jörg Schaible-5
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ImmutablePair and compareTo()

Matt Sicker
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
underlying objects would be nice.

On 3 March 2017 at 09:58, Jörg Schaible <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: ImmutablePair and compareTo()

garydgregory
On Fri, Mar 3, 2017 at 8:05 AM, Matt Sicker <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Matt Sicker <[hidden email]>
>



--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: ImmutablePair and compareTo()

Matt Sicker
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 <[hidden email]> wrote:

> On Fri, Mar 3, 2017 at 8:05 AM, Matt Sicker <[hidden email]> 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 <[hidden email]>
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Matt Sicker <[hidden email]>
> >
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> 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 <[hidden email]>