Nicolas <bousque...@gmail.com> writes:
> An interresting point of clojure is that it is dynamically typed. This
> for a reason. There is a tradeoff in performance but the benefit is
> that the code is shorter, more expressive and reusable.
>
> Type hinting should be exceptionnal and used only in critical areas
> when you see a huge boost in performance. And if you need this boost.
>
> I think then that's the library author responsability and own right to
> figure by himself where ultimate performance is needed or instead
> where greater flexibility is to be prefered.
Type hints are only for Java interop, and when dealing with java
objects, I don't think it's false to think in java. For example, when I
have
(defn do-something [foo]
(+ (.doubleValue foo) 2))
in my library, then I clearly assume foo to be some java object that is
instance of a class that defines some doubleValue method with zero
parameters and which returns some number (at minimum, although the name
suggests a double). Feeding anything else in it that doesn't fulfill
that assumption (no such method, other return type) will blow up anyway,
because + only works for numbers. So in that case, why shouldn't I add
a ^Number type hint to foo, because Number declares the doubleValue
method?
If I really want that function to be open for other java types I did not
foresee, then I'd use a protocol that clearly documents my assumptions:
(defprotocol CanConvertToDouble
"Protocol for things convertable to a java.lang.Double."
(as-double [this]
"Returns a double representation of this."))
Then I'd extend that protocol to the types I have in mind when
developing that library.
(extend-protocol CanConvertToDouble
Number
(as-double [n]
(.doubleValue n)))
Then my function can work with the protocol abstraction instead of a
concrete type:
(defn do-something [foo]
(+ (as-double foo) 2))
So now I don't need reflection anymore while still being open. If some
user of my library really feels the need to feed his
SomeUserType-objects that don't derive from Number into my function,
then he's fine to do so by extending the protocol to his own java type.
(extend-protocol CanConvertToDouble
SomeUserType
(as-double [n]
(.doSomeFancyStuffToConvertNIntoADouble n)))
That's basically some kind of EULA: "Hereby I agree, that I have read
and fully understood, that Tassilo's library assumes that invoking
as-double on my object returns some java.lang.Number. If I don't
fulfill that contract and my computer explodes, it's my own fault."
Bye,
Tassilo
--
(What the world needs (I think) is not
(a Lisp (with fewer parentheses))
but (an English (with more.)))
Brian Hayes, http://tinyurl.com/3y9l2kf
--
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
