A while back I saw some java slides that elude me now, they mentioned approaches to safety like defensive copying, immutability, etc.. their conclusion at the end, that I seem to remember, was it only really made sense to validate user input, a sort of wall, where anything past the wall is assumed to be valid data. If you do idiomatic things below that layer then it will be easy to match expectations of other programmers, otherwise you'll more likely just slow the system down and go overboard than do anything useful.
Personally, I only care about these assertions when there's a real 'contract' or specification at play, at top-down-designed component boundaries. Any validation happens at the top, and the code below is more flexible and easier to change because of it. On Thu, May 23, 2013 at 1:11 PM, John D. Hume <duelin.mark...@gmail.com>wrote: > On Thu, May 23, 2013 at 11:30 AM, atkaaz <atk...@gmail.com> wrote: > >> So all I was saying above is that it should throw when [] is empty just >> as it does when [] is not empty, but it doesn't throw when empty because >> it's never called (by "it" i mean "false" not "false?") >> > > This sort of behavior is handy for users new to the language but generally > goes against the grain in a dynamic language (e.g., Clojure, Ruby, Python, > JavaScript). If you want libraries to consistently error when you try to > pass the wrong sort of thing to a method or function, there are a whole > bunch of languages that make it inconvenient not to do that (e.g., Haskell, > Scala, Java, Go). > > In a dynamic language this requires extra code in every method or function > that makes assumptions about its arguments' types. People who choose > dynamic languages often do so in part because of how little code it takes > to do powerful things. So I think the communities largely see validation of > arguments as clutter. That doesn't mean it's never done, but it's kept to a > minimum. For example, clojure supports adding :pre and :post conditions to > a fn's metadata, but that feature seems to be used only three times in > clojure itself: twice in clojure.reflect.java and once in clojure.uuid. On > the other hand, many macros in clojure.core validate their usage with the > private assert-args. > > This philosophical bent also comes up in question about how to design a > library so that users can't mess up certain things. In the Java community, > that's a common concern. In Clojure-land, the prevailing wisdom is to > design and document so that it's easy to do the right thing but not worry > much about people who do the wrong thing. > > -- > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
