This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-19
Channels
- # adventofcode (44)
- # announcements (2)
- # aws (9)
- # beginners (166)
- # braveandtrue (16)
- # calva (170)
- # cider (14)
- # cljdoc (9)
- # cljs-dev (4)
- # cljsrn (1)
- # clojars (1)
- # clojure (150)
- # clojure-dev (15)
- # clojure-europe (4)
- # clojure-india (3)
- # clojure-italy (93)
- # clojure-nl (18)
- # clojure-serbia (1)
- # clojure-spec (5)
- # clojure-uk (45)
- # clojurescript (54)
- # cursive (19)
- # data-science (8)
- # datomic (83)
- # emacs (6)
- # events (1)
- # hoplon (3)
- # hyperfiddle (3)
- # jobs (6)
- # jobs-discuss (1)
- # klipse (1)
- # lein-figwheel (6)
- # leiningen (15)
- # lumo (1)
- # nrepl (1)
- # pedestal (15)
- # re-frame (48)
- # reagent (4)
- # reitit (2)
- # remote-jobs (1)
- # rum (2)
- # shadow-cljs (111)
- # spacemacs (10)
- # sql (16)
- # testing (10)
- # tools-deps (5)
@andy.fingerhut I’ve been bitten in the past by the unexpected behaviour of Boolean/valueOf
and Clojure branching logic – I wonder if it impacts on equality, too.
In my specific case, it turns out that grpc-java
creates default values for unspecified message fields using the string constructor, which results in unspecified boolean fields being created with (Boolean/valueOf "false")
, which is truthy in some situations in Clojure.
I remember discussions about this, happening 5-6 years ago but I've since forgotten how the issue manifests
One way you can run into this is via Java serialization. A concrete example is when using Spark and you end up looking at a deserialized Boolean.
Clojure requires that you use the Boolean cached values
Otherwise a Boolean constructed any other way is treated as true, including a boxed false
correct, that’s what I’m talking about
maybe Marc really meant Boolean/parseBoolean? dunno
At least some of the issues about boolean constructors are described on the http://ClojureDocs.org if
page here: http://clojuredocs.org/clojure.core/if
In a Clojure 1.10 REPL at least I see (= false (Boolean. false))
return true
, which looks reasonable. It is using the (Boolean. false)
in an if
or cond
condition that will bite you.
> maybe Marc really meant Boolean/parseBoolean? dunno
Yeah, I can’t remember the exact call used to construct the Boolean – I was debugging through https://github.com/protocolbuffers/protobuf trying to find out what was going on, which lead me to the note about if
that Andy linked to.
I haven't tried it myself, but as it says on that http://ClojureDocs.org page, even Java documentation anti-recommends the use of (Boolean. false) values, so if Google's protobuf implementation in Java returns data structures containing such values, it sounds like an enhancement request might be in order.