2010/5/28 Michael Gardner <[email protected]> > On May 28, 2010, at 12:42 PM, Laurent PETIT wrote: > > > The rule should really always be: no warning at all (with > *warn-on-reflection* set to true, of course). > > I strongly disagree. Why should you care about those sorts of warnings > unless you've already identified a bottleneck that needs elimination?
Because in this world of non typed vars and highly generic code, I tend to consider compiler warnings being of similar importance to compiler errors in statically typed languages. With the additional benefit that since they are warnings, they don't get in your way while you're experimenting and shaping your project's code. But one should consider with care, when commiting code, letting the warnings accumulate "out of control" to the point you're not able to spot the apparition of new ones. > IMO the "rule" should be: write it the simplest way you can first, then > optimize only what your benchmarks tell you needs optimizing. > Reflection warnings not only reflect potential optimization problems, but also potential bugs, like for the reflection warnings I added in the above example: the String.replace() function is highly overloaded in such a way that if you pass 2 String to it, one function will be taken, but if you explicitly cast the Strings to CharSequences, another implementation (not considering the first string to be a regexp) is taken. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
