We still have a sizable Java chunk here closely interacting with Clojure and fully agree with #1 and #2.
Interop is environment specific and should not be driving the Clojure language design. Otherwise Clojure generics would have to "bend" to Java, CLR, JS and future implementations in other environments, loosing its identity along the way and creating a Babel tower. Luc P. On Thu, 20 Oct 2011 09:00:23 -0400 Stuart Halloway <stuart.hallo...@gmail.com> wrote: > > Yes, I understand the behavior perfectly well. The primitive int > > gets converted to a Long immediately, as this code demonstrates: > > > > user=> (class (Integer/parseInt "5")) > > java.lang.Long > > > > The int isn't being "boxed" into a Long -- the type is being > > changed. > > > > I'm aware that I can "fix" things by converting the type back to an > > Integer manually, but that's not the point. Changing the types is > > unusual behavior that leads to hard to track down bugs like I ran > > into with the ClassCastException. My proposal still stands. > > > > -Nathan > > Somebody has to work hard: either users of collections, or interop > callers. The current behavior makes things "just work" for > collections, at the cost of having to be explicit for some interop > scenarios. > > There are two reasons to favor collection users over interop users: > > (1) Interop problems are local, and can be resolved by checking the > type signature at the point of the problem. Collection key problems > are global and break the composability of collections. It is a *huge* > benefit of Clojure that collections are sane. > > (2) There are a lot more lines of code working with collections than > doing interop. > > Stu > -- 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
