Re: boolean java interopt puzzle/bug?!
Thanks for the help and clarifications. My problem is that I'm working on a tool, as a part of my thesis, to randomly execute annotated java classes to try discover its behavior. So if a class has a (b|B)oolean field and I read its value using reflection it returns (using Field.get()) a Boolean that for clojure will be always false. In order to solve this issue I created the follow fn: (defn- get-val [^java.lang.reflect.Field f instance] (let [value (.get f instance)] (if (instance? java.lang.Boolean value) (boolean value) value))) Thanks and regards, -- Bauna On 10/06/2013 10:57 PM, Andy Fingerhut wrote: There is also this page on ClojureDocs that might shed some light on this quirk: http://clojuredocs.org/clojure_core/clojure.core/if On Sun, Oct 6, 2013 at 6:14 PM, Rob Browning r...@defaultvalue.org wrote: Gary Trakhman gary.trakh...@gmail.com writes: Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed reasons (I think) anything that checks for truthiness uses java's ==, which will fail on any new Boolean object. Usually, this isn't a problem, but sometimes it is. You can see that this assumption is pervasive by looking at the implementations of 'true?' and 'false?', which use identical? and the check for != Boolean.FALSE in https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569 ...and further, my understanding is that the Boolean constructors are more or less considered a mistake, and you should effectively never use them. For example: http://rayfd.me/2007/01/17/the-evil-boolean-constructors/ Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- -- 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. -- -- 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
boolean java interopt puzzle/bug?!
Hey Devs, I have fighting against an issue that can summarized in the following line: user= (not (new java.lang.Boolean false)) false Is that behavior correct? Because if I run: user= (type false) java.lang.Boolean Can someone help me to understand it? Thanks, -- Bauna -- -- 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.
Re: boolean java interopt puzzle/bug?!
Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed reasons (I think) anything that checks for truthiness uses java's ==, which will fail on any new Boolean object. Usually, this isn't a problem, but sometimes it is. You can see that this assumption is pervasive by looking at the implementations of 'true?' and 'false?', which use identical? and the check for != Boolean.FALSE in https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569 On Sun, Oct 6, 2013 at 5:27 PM, Pablo Nussembaum bau...@gmail.com wrote: Hey Devs, I have fighting against an issue that can summarized in the following line: user= (not (new java.lang.Boolean false)) false Is that behavior correct? Because if I run: user= (type false) java.lang.Boolean Can someone help me to understand it? Thanks, -- Bauna -- -- 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.
Re: boolean java interopt puzzle/bug?!
Gary Trakhman gary.trakh...@gmail.com writes: Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed reasons (I think) anything that checks for truthiness uses java's ==, which will fail on any new Boolean object. Usually, this isn't a problem, but sometimes it is. You can see that this assumption is pervasive by looking at the implementations of 'true?' and 'false?', which use identical? and the check for != Boolean.FALSE in https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569 ...and further, my understanding is that the Boolean constructors are more or less considered a mistake, and you should effectively never use them. For example: http://rayfd.me/2007/01/17/the-evil-boolean-constructors/ Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- -- 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.
Re: boolean java interopt puzzle/bug?!
There is also this page on ClojureDocs that might shed some light on this quirk: http://clojuredocs.org/clojure_core/clojure.core/if On Sun, Oct 6, 2013 at 6:14 PM, Rob Browning r...@defaultvalue.org wrote: Gary Trakhman gary.trakh...@gmail.com writes: Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed reasons (I think) anything that checks for truthiness uses java's ==, which will fail on any new Boolean object. Usually, this isn't a problem, but sometimes it is. You can see that this assumption is pervasive by looking at the implementations of 'true?' and 'false?', which use identical? and the check for != Boolean.FALSE in https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569 ...and further, my understanding is that the Boolean constructors are more or less considered a mistake, and you should effectively never use them. For example: http://rayfd.me/2007/01/17/the-evil-boolean-constructors/ Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- -- 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.
