I think there is another reasonable case for a type hint. If you've
written a function that is not generic, where one type and only one
type will do, then why not add a type hint as a form of documentation
if nothing else?

On Nov 21, 1:58 pm, Nicolas <bousque...@gmail.com> wrote:
> Hi !
>
> 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.
>
> Bye,
>
> Nicolas.
>
> On Nov 21, 5:12 pm, Tassilo Horn <tass...@member.fsf.org> wrote:
>
>
>
>
>
>
>
> > 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

Reply via email to