On Sunday, October 23, 2011 5:21:52 PM UTC-4, Rich Hickey wrote:
>
> Hi all,
>
> This reply is to the thread, not Luc specifically.
>
> Thanks everyone for your feedback and input.
>
> I have pushed 3 commits:
>
> 1) Fixes the inconsistency between the hash function used by Clojure maps
> (was .hashCode) and =. Thanks Paul for the report.
>
> 2) Changes core/hash to return the result of this hashing function. Thus,
> it returns a different value than does .hashCode for Integers, Shorts,
> Bytes and Clojure collections. Feedback welcome.
>
> 3) Only due to the first fix, it now becomes possible to box ints to
> Integers without much grief. This commit implements that for evaluation
> purposes, and is not a commitment to that policy. Note well that while in
> the first commit the answer is clear, on this point there is always going
> to be a tradeoff and there is no 'right' answer.
>
> Here are the issues as I see them:
>
> First, note there is no 'following' of Java semantics as an objective.
> Java semantics are that Integers are never equal to Longs, and I presume no
> one wants to go back to that.
>
> Second, boxing is a change of type, period. There is no valid complaint
> that 'you changed my type'. int != Integer either.
>
> Third, there are 2 scenarios in consuming things you box in Clojure from
> Java:
>
> a) You control the Java. In this case, having Clojure make everything
> uniform (Longs) make things easier for you. There is no heterogeneousness
> regardless of the source or manipulation of numbers, and can always expect
> Longs.
>
> b) You don't control the Java. In this case you must match consuming
> expectations i.e. conforming to Java promotion, types of generics etc.
> ***This will *always* require vigilance and explicitness due to arithmetic
> conversions etc***. Auto promotion is only one part. Note that this is true
> in Java as well - while type checker may scold you, you still have to
> cast/coerce on mismatch.
>
> Even with the auto box change, you are only an arithmetic operation away
> from having the problem again. For instance in the original report,
> wrapping .getValue with dec generates an interop mismatch again:
>
> (let [amap {1 (dec (.getValue obj))}] …)
>
> There is no way we are going to 'fix' that by adopting Java's numeric
> tower, which is dangerous and requires static types. The bottom line is
> specific type requirements on the Java side require explicit boxing on
> order to have correct and non-brittle code.
>
> The final consideration is collection equality. When Clojure autoboxes to
> Longs, you get homogeneous collection contents, and thus .equals is still
> true for the collection on the Java side, vs random - 'depends on where I
> got the contents from and what I did with them'.
>
> FYI - there are the RT/box functions that box as per Java. These could be
> exposed in Clojure.
>
> -----
> In short, having autoboxing match Java does not really free you from your
> responsibility to create specific boxed types when you need them on the
> Java side. I.e., Clojure can't help you.
>
> On the flip side, when you are in charge of the Java code, Clojure's being
> more consistent makes things more consistent on the other side and *does*
> give you less to do to make sure things work.
>
> I prefer what we had (auto box to Longs), but I think it matters a
> somewhat less now with = consistent hashing. If we decide to revert to that
> we can discuss making auto boxing of short and byte consistent.
> -----
>
Rich,
In Clojure 1.4.0-beta3 ints are boxed as Integers.
Clojure 1.4.0-beta3
user=> (map type [(byte 1) (short 1) (int 1) (long 1)])
(java.lang.Byte java.lang.Short java.lang.Integer java.lang.Long)
Based on the above and my conversation with you at the Conj you seemed to
be pretty convinced that ints should be boxed as Longs. You made a
temporary commit to box them as Integers
(https://github.com/clojure/clojure/commit/a2e4d1b4eaa6dad26a1a96b9e9af129cccca9d10),
then Stu Halloway reverted it
(https://github.com/clojure/clojure/commit/abfa803838a1884d0c5112bc6b876cf33a8a05cc),
then he reverted the revert
(https://github.com/clojure/clojure/commit/798a98bc1b844b0fe08e9309886823cf7ca92604).
Are we still in the temporary period for evaluation purposes? Have you
changed your mind? If so, I'd be interested to hear why. Should we expect
this behavior from beta3 to change any time soon?
Paul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
