This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-29
Channels
- # architecture (14)
- # beginners (184)
- # boot (25)
- # cider (23)
- # clara (9)
- # cljsjs (13)
- # cljsrn (5)
- # clojure (140)
- # clojure-austria (1)
- # clojure-dev (24)
- # clojure-greece (15)
- # clojure-italy (7)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojure-sanfrancisco (10)
- # clojure-spec (39)
- # clojure-uk (28)
- # clojured (1)
- # clojurescript (26)
- # core-async (3)
- # cursive (13)
- # datomic (44)
- # docs (3)
- # emacs (31)
- # events (2)
- # figwheel (4)
- # fulcro (6)
- # graphql (2)
- # hoplon (5)
- # jobs (11)
- # juxt (4)
- # keechma (19)
- # leiningen (1)
- # off-topic (8)
- # om (8)
- # onyx (18)
- # parinfer (2)
- # re-frame (18)
- # reagent (24)
- # ring (4)
- # rum (2)
- # shadow-cljs (26)
- # sql (15)
- # timbre (6)
- # vim (2)
via #clojure, when specifying a post condition like this, it will never throw:
{:post [nil?]}
would a patch that warns or allows this be welcome?@martinklepsch that's not how post conditions work
user=> (defn foo [x] {:post [number?]} x)
#'user/foo
user=> (foo 'a)
a
user=> (defn foo [x] {:post [(number? %)]} x)
#'user/foo
user=> (foo 'a)
AssertionError Assert failed: (number? %) user/foo (form-init8679983479575350905.clj:1)
use (nil? %)
I’m aware that this is not how they currently work, I’m arguing that the (nil? %)
syntax is… confusing?
so you're saying you want to replace the post condition syntax with a new one
It seems way too easy to write post conditions in a way that will never actually check anything
perhaps a spec that throws if the post condition isn't a form containing %
I’m ok with whatever solution makes this more user friendly, a warning or making my above syntax work
… or something else entirely
Have to say that I do like {:post [nil?]}
though. Not sure why the %
was necessary in the first place?
I bet there's a lot of broken post conditions out there that would break as soon as they are used as intended haha
I think the idea is that you avoid creating an anonymous function just for one code path? not sure though
As just mentioned in #clojure Eastwood linter can detect many of these
… which is great but a large portion of people using/starting with Clojure might not start with Eastwood
And yes, when I first implemented it, I did find several incorrect pre/postconditions in open source Clojure projects I tested on.
If my implementing in Eastwood becomes the primary reason that core developers choose not to implement additional warnings/checks in core for this, then my apologies. I suspect that won't be the reason, though.
this mistake reminds me of the classic newb mistake ('or x y)
which just happens to return the right thing for many test cases
Yeah, didn’t mean to imply that if it came across like that 🙂 Just noticed that this will be pretty confusing for newbies. Even I look up fogus’ article basically every time I want to use pre/post conditions 🙈
The Eastwood docs are hopefully pretty clear on why they give warnings, and what you might be doing wrong, with advice on how to do things correctly in some cases.
No worries. I also didn't mean to imply that core developers will not do something like this. I don't know off the top of my head whether the condition to give a warning here is prone to false positives, but false positives in compiler warnings tend to turn into bug reports/enhancement requests.
2c: investing effort in pre/post conditions is probably low priority given superior capability from spec.
In his REPL-driven development talk, Stuart Halloway said the following: "Projects and files, and the namespace to file name convention and all of that stuff. All of that is a convention that is not necessary at all, and it is important to keep that in mind." Here is the context in case it is relevant: https://github.com/jafingerhut/jafingerhut.github.com/blob/master/transcripts/2017-jun-stuart-halloway-repl-driven-development.txt#L256-L259
Excellent and interesting talk, by the way.
However, that statement confused me. clojure.core/require enshrines this 'convention', doesn't it?