9:43zilti: I don't even have tests yet though ^^ It's mainly to try out how I can get this to work

9:43dysfun: if you can get that working, it might just be as simple as boot javac repl

9:55vdmit11: Hey guys, since clojure.spec is buzzing around, I have a little question. I would like to define specs for protocol methods. That is, when I use `defprotocol`, I would like to define some specs for the methods of this protocol. And I would like these specs to be checked automatically in runtime. So whenever I call the method, I would like some validation to be performed in runtime. And I would not like to do the validation manually in every implementation

9:55 So I would like to have a modified `defprotocol` macro or something that will instrument all methods to perform checks whenever I call the method. Is this possible?

9:56dysfun: 1. write functions that wrap the methods, doing the checks in those

9:56 2. use a multimethod, where you will be able to execute a spec check before it is run

9:58vdmit11: Yeah, I noticed :pre/:post in multimethods, but I think that protocols are more handy for me. Because I have a lot of value objects (records) in may code, and it is super-handy to extend them with implementations of various protocols.

10:01 it also has the advantage that it's actually possible with multimethods ;)

10:01vdmit11: Maybe this is just a personal preference. In my opinion protocols provide more "documentation" of what operations are available on some kind of objects, so they somehow cleaner. Multimethods are good when you have a huge number of implementations of the single method, while protocols look better when you have not just one, but a bunch of coupled methods, and not that many implementations of them.

14:13jonathanj: jeaye: i think it's more or less the same thing, isn't it?

14:42jeaye: jonathanj: Not at all. What Rich is speaking against is preventing the growth of code, and data, by limiting the shape of it to a specific key set. I'm talking about unrestricted growth of data, with the knowledge that a certain key will never be present.

14:43 I think they're fundamentally different. How else would you write the :ret spec for something like dissoc? It's the input map, guaranteed to not have the specified key; it can have anything else though.

15:35TimMc: I should watch the spec keynote. The inability to forbid keys is one of the reasons I haven't bothered to pick up spec.

15:36 I want to protect against misspelling an optional key, basically.

15:42vdmit11: well, a custom predicate function may be used to ensure that all keys belong to some pre-defined set of keys

15:43 so it is possible to forbid keys, but there is no first-citizen support for this

17:18jeaye: TimMc: It's not an inability, as vdmit11 mentioned; it's quite simple, actually. There's just no built-in support for it.