primitives, or BoxedPrimitives? #15

dsaff · 2011-06-08T23:03:32Z

Essentially, should IntSubject take an Integer, or an int, in its constructor? Integer is more general, but requires more book-keeping. The conversation continues...

cgruber · 2011-06-10T15:46:36Z

I'd prefer the boxed primitives. It requires more bookkeeping, but I think the job of this framework is to do the bookkeeping so the test writer doesn't have to. The only book-keeping is really around nulls, I think.

cgruber · 2011-06-10T15:46:52Z

We should resolve this, however, before we implement the float/double side of the house.

dsaff · 2011-06-13T17:59:51Z

I see both sides of the issue, but here's a presentation of just one side

I like the idea of taking primitives because:

(1) developer instincts can be better employed. For example, how many developers know that

! (new Integer(3).equals(new Long(3))

or the exact circumstances under which the below happens?

(x == y && new Integer(x) != new Integer(y))

Since I'd like to lean on Java's definitions as much as possible, I think the primitive definitions hit closer to what people know better.

(2) We can prevent people from ever comparing doubles without a delta. That in and of itself is a huge win.

(3) I'm okay with NPEs erupting instantly when someone tries:

ASSERT.that((Integer)null).is((Integer)null)

(4) I can't figure out a different situation in which auto-deboxing wouldn't Just Work.

cgruber · 2011-06-13T18:08:37Z

Fair, but I think we can handle ASSERT.that(new Integer(5)).is(new Long(5)) under the hood, by coercing all integral values to the widest type possible before comparison.

The same wouldn't be true for inexact floating point stuff, though. Hmm...

Ok - would we have BOTH primitives and boxed types then? I think we should, else we end up with ASSERT.that(new Long(5)) would map to TestVerb.that(Object target) which would be bad (see the other thread on that(Object). I think that's the case that beats #4. And I think it points out the problem of #3, bceause I think that would not match the primitives, but that(Object), no?

On Jun 13, 2011, at 10:59 AM, dsaff wrote:

I see both sides of the issue, but here's a presentation of just one side

I like the idea of taking primitives because:

(1) developer instincts can be better employed. For example, how many developers know that

! (new Integer(3).equals(new Long(3))

or the exact circumstances under which the below happens?

(x == y && new Integer(x) != new Integer(y))

Since I'd like to lean on Java's definitions as much as possible, I think the primitive definitions hit closer to what people know better.

(2) We can prevent people from ever comparing doubles without a delta. That in and of itself is a huge win.

(3) I'm okay with NPEs erupting instantly when someone tries:

ASSERT.that((Integer)null).is((Integer)null)

(4) I can't figure out a different situation in which auto-deboxing wouldn't Just Work.

Reply to this email directly or view it on GitHub:
https://github.com/dsaff/truth/issues/15#issuecomment-1360647

dsaff · 2011-06-13T19:34:27Z

You're right. We should accept both types, but we should enforce
primitive semantics. Does that sound like the right middle ground?

David

On Mon, Jun 13, 2011 at 2:08 PM, cgruber
reply@reply.github.com
wrote:

Fair, but I think we can handle ASSERT.that(new Integer(5)).is(new Long(5)) under the hood, by coercing all integral values to the widest type possible before comparison.

The same wouldn't be true for inexact floating point stuff, though. Hmm...

Ok - would we have BOTH primitives and boxed types then? I think we should, else we end up with ASSERT.that(new Long(5)) would map to TestVerb.that(Object target) which would be bad (see the other thread on that(Object). I think that's the case that beats #4. And I think it points out the problem of #3, bceause I think that would not match the primitives, but that(Object), no?

On Jun 13, 2011, at 10:59 AM, dsaff wrote:

I see both sides of the issue, but here's a presentation of just one side

I like the idea of taking primitives because:

(1) developer instincts can be better employed. For example, how many developers know that

! (new Integer(3).equals(new Long(3))

or the exact circumstances under which the below happens?

(x == y && new Integer(x) != new Integer(y))

Since I'd like to lean on Java's definitions as much as possible, I think the primitive definitions hit closer to what people know better.

(2) We can prevent people from ever comparing doubles without a delta. That in and of itself is a huge win.

(3) I'm okay with NPEs erupting instantly when someone tries:

ASSERT.that((Integer)null).is((Integer)null)

(4) I can't figure out a different situation in which auto-deboxing wouldn't Just Work.

Reply to this email directly or view it on GitHub:
https://github.com/dsaff/truth/issues/15#issuecomment-1360647

Reply to this email directly or view it on GitHub:
https://github.com/dsaff/truth/issues/15#issuecomment-1360707

cgruber · 2011-06-13T19:52:41Z

Ok. I'm still uncomfortable with the NPE case, but I'm willing to live with it, as long as it's really documented. But then, I'm uncomfortable with null-handling in Java in general.

Christian.

On Jun 13, 2011, at 12:34 PM, dsaff wrote:

You're right. We should accept both types, but we should enforce
primitive semantics. Does that sound like the right middle ground?

David

On Mon, Jun 13, 2011 at 2:08 PM, cgruber
reply@reply.github.com
wrote:

Fair, but I think we can handle ASSERT.that(new Integer(5)).is(new Long(5)) under the hood, by coercing all integral values to the widest type possible before comparison.

The same wouldn't be true for inexact floating point stuff, though. Hmm...

Ok - would we have BOTH primitives and boxed types then? I think we should, else we end up with ASSERT.that(new Long(5)) would map to TestVerb.that(Object target) which would be bad (see the other thread on that(Object). I think that's the case that beats #4. And I think it points out the problem of #3, bceause I think that would not match the primitives, but that(Object), no?

On Jun 13, 2011, at 10:59 AM, dsaff wrote:

I see both sides of the issue, but here's a presentation of just one side

I like the idea of taking primitives because:

(1) developer instincts can be better employed. For example, how many developers know that

! (new Integer(3).equals(new Long(3))

or the exact circumstances under which the below happens?

(x == y && new Integer(x) != new Integer(y))

Since I'd like to lean on Java's definitions as much as possible, I think the primitive definitions hit closer to what people know better.

(2) We can prevent people from ever comparing doubles without a delta. That in and of itself is a huge win.

(3) I'm okay with NPEs erupting instantly when someone tries:

ASSERT.that((Integer)null).is((Integer)null)

(4) I can't figure out a different situation in which auto-deboxing wouldn't Just Work.

Reply to this email directly or view it on GitHub:
https://github.com/dsaff/truth/issues/15#issuecomment-1360647

Reply to this email directly or view it on GitHub:
https://github.com/dsaff/truth/issues/15#issuecomment-1360707

Reply to this email directly or view it on GitHub:
https://github.com/dsaff/truth/issues/15#issuecomment-1361252

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

primitives, or BoxedPrimitives? #15

primitives, or BoxedPrimitives? #15

primitives, or BoxedPrimitives? #15

primitives, or BoxedPrimitives? #15

Comments