Il giorno martedì 3 luglio 2012 15:33:17 UTC+2, Herwig Hochleitner ha scritto: > > The problem with using type hints for doc is, that they actually alter > runtime behavior, non - locally: > - They replace expensive reflective method call sites with casts to a > known type > - Hence they effectively narrow the accepted type at the call site > But the above would only apply in case of interop calls, right? Putting a Protocol as a return type hint of an fn, we're always calling clojure fns on such result types. We should then not suffer from any of the two limitations.
- They change the exception thrown in error cases to ClassCastException > That's something that might be quite a deal breaker. Again, would this happen in any situation other than interop calls? > None of those caveats may be a problem for your use case, but they are the > reason type hints > are considered an optimization technique rather than documentation. > > Also for real documentation, type hints lack expressivenes (unions? > parameters? function types?). > Indeed, they would not alone provide all the needed documentation. I guess the idea would be to have some quick hints (no pun intended) for the developer looking at the sources. For using types as documentation, while also being able to statically check > them, keep an eye out for > https://github.com/frenchy64/typed-clojure > That's probably a bit too far already. While I might go for the type hints as documentation, I'm not quite interested in full type safety yet. Thanks, c. > -- 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
