Allow pre and post-conditions in defprotocol and deftype macros

Question

The fn special form and the defn macro allow pre- and post-conditions. It would be nice if one could use that conditions also in method declarations of the defprotocol and deftype macro.

Currently I use the extend function as workaround where one can specify the methods using a map of keyword-name and fn special form.

Answer 1

Comment made by: michael-drogalis

Using {{:pre}} and {{:post}}, IMO, isn't a good idea. Handling assertions is a two part game. The mechanism needs to account for both detection and reaction, and the latter is missing.

This isn't a perfect work-around, as it's a little verbose, but using (link: https://github.com/MichaelDrogalis/dire text: Dire) might work better than using extend. In addition, you get the "reaction" functionality that's missing from {{:pre}} and {{:post}}

Example for protocol preconditions: https://gist.github.com/4471276

Answer 2

Comment made by: akiel

@Michael I read your (link: https://gist.github.com/4471276 text: gist) and the README of (link: https://github.com/MichaelDrogalis/dire text: Dire). I think the supervision concept of Erlang has it's places but I don't like it for pre- and post-conditions. For me, such conditions have two proposes:

1. they should document the code and
2. they should fail fast to detect failures early.

To support my first point, your pre- and post-conditions are just lexical too far away from the actual function definition. For the second point: I think in the case of violations the program should just crash. One could maybe wrap some part of the program with one of your exception supervisors handling an AssertionError. But I don't think that handling pre- and post-condition violations for individual functions is a good thing.

Answer 3

Comment made by: michael-drogalis

@Alexander Indeed, your points are correct. Dire is meant to be exactly what you described. Lexically removed from application logic, and opportunity to recover from crashing. That was my best shot at aiding your needs quickly, anyway. :)

Answer 4

Reference: https://clojure.atlassian.net/browse/CLJ-1141 (reported by akiel)

Answer 5

I wonder if this isn't possible because of the associated interfaces being implementable in Java. Any such implementations wouldn't include the pre and post conditions, which could break assumptions.

Comments

It could be done on `defrecord` impls. It relies on `maybe-destructure`, following a similar code path as `fn`'s redefinition in `clojure/core.clj`. Could just copy-paste that in.

I suspect this would work and work well, but i know there are edge cases I'm not considering and there's probably some cost-benefit for speed etc that has been accounted for. @alexmiller, any thoughts?