Luc, what you're saying sounds to me like "this is the way it is so
deal with it". Can you give me some concrete code snippets showing why
it's better to box ints as Longs? Do you really think the following is
at all intuitive?
user=> (class (Integer/parseInt "1"))
java.lang.Long
user=> (class (Integer/valueOf "1"))
java.lang.Integer
-Nathan
On Oct 20, 10:27 pm, Luc Prefontaine <lprefonta...@softaddicts.ca>
wrote:
> The "weirdness" here is that you seem to confuse the Java context and the
> Clojure
> context. They are not the same. Clojure has to satisfy to performance and
> consistency
> criterias. It's a language of it's own, not a Java offspring.
>
> user=> (class (Integer/parseInt "1"))
> java.lang.Long
> user=>
>
> Integer/parseInt returns a primitive type. Not a boxed Integer object.
> If used as a key in a map or anything else in Clojure, it will get promoted
> to a long value as per the math
> promotion rules (long/double representation). Obviously needed if it is to be
> used later in a computation
> otherwise it would break math operations consistency by allowing mixed
> int/long operands.
>
> If passed as an interop parameter it will retain it's int type.
>
> user=> (class (Integer/valueOf 1))
> java.lang.Integer
>
> Integer/valueOf returns an Integer object, not a primitive type.
> It's an object, not a primitive type, Clojure will not change it.
> If used as a key in a Clojure map or any Clojure data structure, it will
> retain its object status.
>
> Just cast your keys accordingly if you want Integer objects as keys.
> In your short example, 1 as a key will not do it, it gets promoted to
> primitive long.
>
> You may not recall but in Java, int used not to be compatible with Integer
> objects.
> It's only since java 5 that you can assign an Integer object to a primitive
> int.
> That's the compiler tricking things to allow you to do that. In the JVM
> there's still
> not represented in the same way.
>
> The above Integer member functions and their behavior have nothing to do with
> Clojure.
> They result from bad decisions made years ago when designing Java and the JVM
> and you are blaming
> Clojure for not handling them according to some patch implemented afterward
> in the Java compiler.
>
> You ran in the ClassCast exception by yourself. Clojure did not push you into
> it.
> When using Java interop you have to obey to Java rules and bend accordingly.
> It's not Clojure that needs to bend, it's you to adapt to the interop
> restrictions/conventions.
>
> If Java expects an Integer object somewhere make sure you are providing it.
>
> Luc P.
>
> On Thu, 20 Oct 2011 21:11:41 -0700 (PDT)
>
>
>
>
>
>
>
>
>
> nathanmarz <nathan.m...@gmail.com> wrote:
> > Now I'm confused. So when I do this:
>
> > (def i (Integer/parseInt "1"))
>
> > Is "i" a primitive int, a primitive long, or a Long object?
>
> > I was under the impression that it was a primitive int based on
> > Justin's test code, but when I run "(primitive-type i)" in the REPL it
> > tells me :object.
>
> > If "i" is a primitive int, then the only change I'm proposing is that
> > if Clojure needs to box that value later on, that it box it as an
> > Integer instead of a Long. This change in behavior would not affect
> > primitive number performance since it's at a point when Clojure is
> > already boxing.
>
> > If "i" is a primitive long (which is what I thought was happening
> > originally), I propose that Clojure box the value as an Integer unless
> > you wrap the form in a "(long ...") form. In the latter case Clojure
> > would do what it's doing currently so you can still get the
> > performance if you need it. The difference is that you're being
> > explicit about the type changing so there's no possible confusion in
> > that regard.
>
> > Finally, if "i" is a Long object, I propose that it instead be boxed
> > as an Integer object.
>
> > Note that I am not saying:
>
> > 1. That Clojure always box primitives into an object form
> > 2. That Clojure implement 32 bit arithmetic
>
> > In all these cases, you can still get maximum performance without
> > Clojure changing ints to longs. Please correct me if there's something
> > I'm missing here.
>
> > Stu's argument from above is that Clojure boxes ints to Longs instead
> > of Integer to avoid weirdness with hashcode/equality in collections.
> > This is a reasonable point, but consider this code example:
>
> > user=> (def m1 {(Integer/valueOf "1") 2})
> > #'user/m1
> > user=> (def m2 {(Integer/parseInt "1") 2})
> > #'user/m2
> > user=> (map class (keys m1))
> > (java.lang.Integer)
> > user=> (map class (keys m2))
> > (java.lang.Long)
>
> > Clojure doesn't prevent you from putting Integer objects in
> > collections. So there are cases where you still need to do type
> > coercion yourself. Given that Clojure can't hide this problem
> > completely from you, I think it's better that it treat "int" and
> > "Integer" consistently by boxing ints as Integers. Then there's no
> > weirdness like I ran into with getting ClassCastExceptions because the
> > type changed.
>
> > -Nathan
>
> > On Oct 20, 6:19 pm, David Nolen <dnolen.li...@gmail.com> wrote:
> > > On Thu, Oct 20, 2011 at 4:11 PM, nathanmarz <nathan.m...@gmail.com>
> > > wrote:
> > > > I'm not sure we're arguing about the same thing. I think that
> > > > Clojure only supporting 64 bit primitive arithmetic is fine, and
> > > > I'm not proposing that it support 32 bit primitive arithmetic.
> > > > The sole point of contention is what Clojure does when it has to
> > > > box a primitive int. I think this is orthogonal to primitive
> > > > args/return, but correct me if I'm wrong.
>
> > > If 32bit ints are allowed to exist then the various numeric
> > > operators must handle them. If the numeric operators handle them
> > > then primitive arg and return should probably be supported. But
> > > that would exponentially increase the number of interfaces required
> > > for primitive arg return support.
>
> > > David
>
> --
> Luc P.
>
> ================
> The rabid Muppet
--
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
