Herwig Hochleitner <hhochleit...@gmail.com> writes:
Hi Herwig,
> In principle you're right. But you have to keep in mind, that type
> hints actually alter runtime behavior.
>
> A hinted call tries to cast its argument into the desired type,
> possibly resulting in a type cast exception. An unhinted call, on the
> other hand, just looks for the signature.
>
> So in essence a hinted call can fail for cases where an unhinted call
> succeeds, effectively reducing composability at a type level
> (polymorphism).
Hm, indeed. This function works for any java object that has a
zero-parameters doubleValue() method.
(defn double-val [x] (.doubleValue x))
In contrast,
(defn double-val [x] (.doubleValue ^Integer x))
will fail for (double-val 7), because by default any integer is a Long
in Clojure 1.3. However, one could go with
(defn double-val [x] (.doubleValue ^Number x))
instead, and that works fine for Integer, Long, Double, ... But of
course, it's not applicable for
class Foo { String doubleValue() {return "foo";} }
whereas the non-type-hinted version is. Note that this doubleValue()
method doesn't even return a double.
But is that really an issue? I mean, since you cannot use such duck
typing in Java itself (except in terms of reflection), any method
defined for more than one class with shared, consistent semantics is
declared in some common parent class or interface which you can use for
your type hint.
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
