This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-26
Channels
- # aws (1)
- # beginners (15)
- # boot (30)
- # cider (13)
- # cljsrn (16)
- # clojure (458)
- # clojure-dev (15)
- # clojure-france (131)
- # clojure-greece (124)
- # clojure-korea (2)
- # clojure-spec (42)
- # clojure-uk (115)
- # clojure-ukraine (1)
- # clojurescript (103)
- # component (18)
- # cryogen (1)
- # datomic (4)
- # dirac (3)
- # figwheel (1)
- # funcool (13)
- # hoplon (60)
- # luminus (2)
- # off-topic (2)
- # om (28)
- # onyx (45)
- # parinfer (28)
- # pedestal (1)
- # proton (23)
- # re-frame (18)
- # reagent (36)
- # ring (1)
- # ring-swagger (5)
- # untangled (13)
- # vim (9)
@alexmiller it would be better as a s/map-of
but afaik I can't use that in a regex
I don't have any explicit keys
Well then sounds good
Any registered keys will get checked
that would be bad actually
I'm trying to spec gen/hash-map
come to think of it I can just do (s/* (s/cat :k keyword? :gen gen?))
and that's perfect
So I'm specing some macros
And it seems common for there to be macro args where there's a straightforward spec for the runtime value, but the macrotime form could be almost anything
So my first thought is to use any?
, but that's unsatisfying since it doesn't tell users anything and doesn't even try to catch problems evident at macroexpansion time
But anything fancier would be somewhat complex
So I'm wondering if it's worth it
Or if we should just expect macro specs to have a lot of any?s in them
@gfredericks I think your macro specs shouldn't be (can't be?) concerned about runtime semantics
I’ve spent a fair amount of time looking at this and in general, it’s quite common for :ret to not be worth spec'ing
and in that you should just omit it
currently macros are skipped during check and instrument only checks :args, so there is not much value in spec’ing :ret anyways beyond docs
for :args where some can be scoped but others can’t, I think use of any? is fine (you can see some of this in the specs I’ve done in clojure.core.specs)
and then consider what you are expanding to - sometimes it’s better to spec that instead (particularly if it bottoms out at a function)
That makes sense; thanks
Is there a suggested approach to building specs in Clojure-1.8 code in anticipation of the 1.9 release? The “alpha” label puts managers off systems that are rapidly going into production, but I would rather be writing specs as I write code, rather than trying to go back to older code and updating it after 1.9 comes out.
i haven't used it, but https://github.com/tonsky/clojure-future-spec is the effort i've heard about
@quoll Any chance that you can persuade them that Clojure 1.9 Alpha = Clojure 1.8 + spec?
not to shoot down a direction towards more spec usage, but that is not exactly true and will become less so
1.9 is still alpha for good reasons and will not go beta until there are a few more things that have been stabilized. It is still reasonably likely that there will be significant changes in the spec internals.
most of that would probably not affect the api but it may affect the idea of forms as the information model for specs
there is a lot of concern that we get certain parts of spec “right” as they will be very difficult to change later
so if you’re worried about investing in something that might change, then your managers are right and you should hold off :)
if you’re worried about using alpha software because it may have known and significant bugs, you should also hold off, because there are some :)
1.9 beta 1 to us signals that the first part (deciding what features to include and provide) is over
1.9 rc1 signals that we believe the major bugs have been fixed
That said, I think the two approaches are to use clojure-future-spec with 1.8 or to separate your specs from your core so that you can build and deploy with 1.8 but test with 1.9 if you like
Understood. My point was more that clojure.spec is (almost) the only new thing in 1.9 so the risk of using the current alphas is actually very low, as far as existing 1.8 behavior is concerned.
I like the suggestion to have a 1.8-buildable system and an option to test against 1.9 with spec on top of that.
For us, we’ve used Clojure Alpha builds in production dating back to 1.3 Alpha 7 or 8 in 2011 and we’ve found it amazingly stable. We find the benefits of being able to leverage new features far outweighs the risks and I think we’ve only had to roll back one or maybe two prerelease builds in those five years.
@seancorfield we’ve had several regressions related to the changes in destructuring and namespaced map syntax
Yup, and there are often small regressions or breaking changes in each release but those have either not affected us or been very minor impact issues.
I can certainly understand some companies being alpha-averse tho’. With some of the projects I maintain, I’ve encountered companies who won’t even consider an RC build. I find the most risk-averse companies tend to be the ones with the worst test coverage and therefore more likely to be unable to detect a regression in their own code… 😐
I think the Clojure/core team has done an incredible job of stability with Clojure releases over the years.
We always run our test suite against both our regular selected Clojure release and against Clojure master snapshots to catch any new breaking changes early.