As James said it is correct, but maybe not intuitive. Intuitively we think an integer isn't empty, but actually it is a non-sensical question - Integers can no more be empty than they can be full.
I noticed that Clojure's use of abstractions, and sticking to those abstractions is far greater than in other languages (I used at least) and getting on board with that really helps. Sure, you could ask _the data structure holding the value of an int_ whether it is 'full' in some sense, but that isn't the point. The point is that an 'Integer' (abstraction) has no sense of 'emptiness' or 'fullness'. On 22 July 2016 at 23:22, James Reeves <ja...@booleanknot.com> wrote: > On 22 July 2016 at 16:42, Peter Romfeld <peter.romfeld...@gmail.com> wrote: >>> >>> >>>> >>>> Im frustrated with `empty?` throwing exceptions for Long and Keyword >>> >>> >>> What should happen? Asking whether an integer or keyword is "empty?" >>> doesn't really make sense IMO, and if it doesn't make sense, it should throw >>> an exception. >> >> >> well its a fn?... "?" ! i would only expect a boolean out of it, of course >> if you read doc and look implementation it makes sense what it does, i still >> think that a function called "empty?" should not throw up, if its an Number >> or Keyword its in my opinion not an empty value! (i understand that a Number >> or Keyword is not sequential.. but then call it "not-seq?") > > > I think your expectation is perhaps wrong in this case. Predicates should > throw an exception on invalid inputs. If you're passing a number or keyword > to `empty?` then there's an error in your code. Throwing an exception rather > than failing silently is absolutely the right thing to do. > > The `empty?` function isn't particularly unusual in throwing exceptions. > `(pos? "foo")` will throw an error, as will `(> "foo" 1)`. If you pass an > input that doesn't make sense, then an exception should be thrown. > >>>> security features in most frameworks are just smoke and mirrors, >>>> functions that dont actually do what they should do... >>> >>> >>> Do you have an example? >> >> >> I dont want to make negative advertisement, but its about csrf, and >> giving false sense of being taken care of for people who dont fully >> understand it > > > I maintain Ring-Anti-Forgery, so if it's anything to do with that, feel free > to raise a concern. Maybe the documentation can be improved. > > - James > > -- > 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/d/optout. -- 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/d/optout.
