This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-16
Channels
- # aleph (1)
- # aws (1)
- # beginners (23)
- # boot (33)
- # cider (15)
- # cljs-dev (4)
- # clojure (73)
- # clojure-dev (18)
- # clojure-italy (8)
- # clojure-russia (7)
- # clojure-serbia (1)
- # clojure-spec (8)
- # clojure-uk (118)
- # clojure-ukraine (3)
- # clojurescript (34)
- # code-art (1)
- # community-development (24)
- # cursive (21)
- # data-science (3)
- # datomic (72)
- # defnpodcast (1)
- # fulcro (77)
- # graphql (4)
- # hoplon (8)
- # jobs (3)
- # luminus (3)
- # lumo (7)
- # off-topic (3)
- # onyx (17)
- # other-languages (7)
- # pedestal (1)
- # perun (1)
- # protorepl (21)
- # re-frame (91)
- # ring (4)
- # ring-swagger (18)
- # shadow-cljs (22)
- # spacemacs (37)
- # specter (1)
- # sql (23)
- # test-check (4)
- # unrepl (29)
- # utah-clojurians (3)
- # vim (36)
- # yada (10)
@tjg Given nil-punning seems pretty core to idiomatic usage (at least in Clojure), I'd be surprised to find any goodarguments for that. I'd certainly be interested in reading anyone's attempted arguments on that topic tho'...
there is this: https://bsima.me/clog/robust-clojure-nil.html
That's not an argument against Clojure having nil. It's basically just good advice about idiomatic handling of nil (even tho' he seems to want to avoid calling it nil-punning -- up until the last paragraph!).
ive found that the use of nil punning can bite me when i go to extend some behavior. and then i need more information passed along so i'm always returning a map of stuff. so previously it would be (if-let (analyze-token token) ....)
but then i want to start passing more information back like why the token was invalid, the nil punning causes a pretty big diff and takes the new information of failure or other things as success, since success just meant not nil in the past