There's a nice explanation on why Clojure has BigInt in Clojure
Programminghttp://www.clojurebook.com/ (page
428). Like Mikera wrote, there were two reasons: one was that Java's
BigInteger's hashCode is not consistent with Long's hashCode. Secondly
Clojure BigInts have been optimized for performance: while all operations
involving BigIntegers must be performed using its (slower) software-based
implementations, Clojure optimizes math involving BigInts to use primitive
(much faster) operations when possible, as long as the values involved are
withing the range of primitive 64-bit longs.
On Monday, 3 February 2014 03:47:41 UTC+2, Mikera wrote:
It would be a bad idea to wrap up everything in custom types:
a) It would add a performance overhead. Better to use the Java types
directly - they are very well optimised on the JVM
b) It would make it much harder to use Java libraries and APIs. Java APIs
expect the correct Java type, and wouldn't understand clojure.lang.String
for example
c) There's no real advantage to reinventing the wheel. The Java types are
already pretty good for what they are designed for, e.g. String is fast and
immutable.
d) It would be a lot of extra work. People have better things to do in
this community, I think!
The clojure.lang.BigInt is a special case - There was probably some good
reason to reimplement java.math.BigInteger (perhaps: performance? getting a
consistent hashcode?)
Likewise clojure.lang.Ratio doesn't have a good equivalent in the Java
API, so needed to be a new implementation.
On Monday, 3 February 2014 06:50:01 UTC+8, Mark Gandolfo wrote:
I tried asking this on twitter and wasn't getting my question across in
140 characters so I decided to post here.
I'm curious as to why Clojure as a language hasn't abstracted/hidden all
of Java's classes and created their own in the Clojure. namespace.
For example
Big Ints are of type and class Clojure.lang.BigInt.
user= (type 1N)
clojure.lang.BigInt
user= (class 1N)
clojure.lang.BigInt
Although a Long is a java.lang.Long both in type and class
user= (class 1)
java.lang.Long
user= (type 1)
java.lang.Long
Similarly a character is of type java.long.Character
user= (type \a)
java.lang.Character
user= (class \a)
java.lang.Character
Again with Java strings
user= (class string)
java.lang.String
user= (type string)
java.lang.String
Although a Strings have a few functions in the clojure.strings namespace
which can be accessed. Why wouldn't clojure.lang.string be the type? And
somehow inherit/remap all of the java string functions?
Was this design decision made during the languages conception to clean up
the clojure namespaces? Or is there another reason that I'm not seeing?
--
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
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
