http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/CLJ-1141 Clojure <p>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.</p> <p>Currently I use the extend function as workaround where one can specify the methods using a map of keyword-name and fn special form.</p> Dos not matter. CLJ-1141

Allow pre and post-conditions in defprotocol and deftype macros

Enhancement Minor Open Unresolved Unassigned Alexander Kiel Wed, 2 Jan 2013 05:08:13 -0600 Mon, 7 Jan 2013 17:28:42 -0600 Release 1.4 1 3 <p>Using <tt>:pre</tt> and <tt>:post</tt>, 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.</p> <p>This isn't a perfect work-around, as it's a little verbose, but using <a href="https://github.com/MichaelDrogalis/dire">Dire</a> might work better than using extend. In addition, you get the "reaction" functionality that's missing from <tt>:pre</tt> and <tt>:post</tt></p> <p>Example for protocol preconditions: <a href="https://gist.github.com/4471276">https://gist.github.com/4471276</a></p> <p>@Michael I read your <a href="https://gist.github.com/4471276">gist</a> and the README of <a href="https://github.com/MichaelDrogalis/dire">Dire</a>. 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: </p> <ol> <li>they should document the code and</li> <li>they should fail fast to detect failures early.</li> </ol> <p>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.</p> <p>@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. <img class="emoticon" src="http://dev.clojure.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> Global Rank