Clojure JIRA

Clojure JIRA http://dev.clojure.org/jira This file is an XML representation of an issue en-us

4.4

649

25-07-2011

[CLJ-1024] Varargs protococol impls can be defined but not called http://dev.clojure.org/jira/browse/CLJ-1024 Clojure <p>The compiler accepts this:</p> <p>(deftype foo []<br/> clojure.lang.IFn<br/> (invoke <span class="error">[this & xs]</span>))</p> <p>However calling ((foo.) :bar) will throw an AbstractMethodError. Wouldn't some checking be desirable?</p> CLJ-1024

Varargs protococol impls can be defined but not called

Enhancement Minor Closed Declined Stuart Halloway Víctor M. Valenzuela patch Tue, 10 Jul 2012 10:09:45 -0500 Thu, 14 Feb 2013 10:03:07 -0600 Wed, 13 Feb 2013 21:22:42 -0600 Release 1.4 Release 1.5 1 2 <p>First of all, clojure.lang.IFn is no protocol but an interface. And it does not declare a</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> public Object invoke(Object... obs) </pre> </div></div> <p>method. It has an `invoke` method with 20 Object parameters followed by an Object... parameter, but to give an implementation for that, you have to specify every parameter separately, and the last Object... arg is just a normal argument that must be an Object[]. That's because Java-varags Type... parameters are just Java syntax sugar, but in the byte-code its simply a Type-array.</p> <p>What your example does is provide an `invoke` implementation for the 2-args version, where the first parameter happens to be named `&`, which has no special meaning here. Take that example:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>(deftype MyFoo [] clojure.lang.IFn (invoke [this & xs] [& xs])) ((MyFoo.) 1 2) => [1 2] </pre> </div></div> <p>But you are right in that `deftype`, `defrecord`, `defprotocol`, and `definferface` probably should error if user's seem to try to use varargs or destructuring.</p> <p>Cheers for a most clarifying response.</p> <p>The fact that the meaning of & gets 'subverted' makes the issue only (slightly) worse, in my opinion.</p> <p>Just for the record, destructuring seems to work, at least for interface impls.</p> <p>> The fact that the meaning of & gets 'subverted' makes the issue only (slightly) worse, in my opinion.</p> <p>I agree. I'll attach a patch which checks for those invalid usages soon.</p> <p>> Just for the record, destructuring seems to work, at least for interface impls.</p> <p>Could you please provide a complete example demonstrating your statement?</p> <p>I'm rather sure that varargs and destructuring don't work for any of defprotocol, definterface, deftype, defrecord, and reify. But you can use varargs and destructuring when providing dynamic implementations via `extend` (or `extend-protocol`, `extend-type`), because those impls are real functions in contrast to methods.</p> <p>I attached a patch. Here's the commit message:</p> <p>Check for invalid varags/destrucuring uses.</p> <p>Protocol, interface method declarations and implementations don't allow for<br/> varags and destructuring support. Currently, for example</p> <p> (defprotocol FooBar<br/> (foo <span class="error">[this & more]</span>))</p> <p>compiles just fine, and & is interpreted as a usual argument that happens to be<br/> named & without special meaning. But clearly, the user wanted to specify a<br/> varags parameter here. The same applies to definterface.</p> <p>Similarly, providing method implementations via defrecord, deftype, and reify<br/> don't allow for destructuring and varags (but dynamic extenions via extend do).</p> <p>So this patch makes defprotocol, definterface, defrecord, deftype, and reify<br/> throw an IllegalArgumentException if any argument vector contains a<br/> destructuring form or varargs argument.</p> <p>Glad you've considered my request.</p> <p>As for destructuring, I was speaking after this example, which may or may not work like it looks like - I don't know.</p> <p>(deftype foo []<br/> clojure.lang.IFn<br/> (invoke [this <span class="error">[a b]</span> c] (println a b c)))</p> <p>((foo.) <span class="error">[1 2]</span> 3)</p> <p>Indeed, descructuring seems to work for method implementations. I'll adapt my patch...</p> <p>Revamped patch. Here's the commit message:</p> <p>Protocol, interface method declarations don't allow for varags and<br/> destructuring support. Currently, for example</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> (defprotocol FooBar (foo [this & more])) </pre> </div></div> <p>compiles just fine, and & is interpreted as a usual argument that happens to be<br/> named & without special meaning. But clearly, the user wanted to specify a<br/> varags parameter here. The same applies to definterface.</p> <p>Similarly, providing method implementations via defrecord, deftype, and reify<br/> don't allow for varags (but dynamic extenions via extend do).</p> <p>So this patch makes defprotocol and definterface throw an<br/> IllegalArgumentException if a user tries to use varargs and destructuring in<br/> method signatures.</p> <p>Similarly, defrecord, deftype, and reify throw an IllegalArgumentException if<br/> any method implementation arglist contains a varargs argument.</p> <p>Tassilo, with your patch 0001-<a href="http://dev.clojure.org/jira/browse/CLJ-1024" title="Varargs protococol impls can be defined but not called"><del>CLJ-1024</del></a>-Check-for-invalid-varags-destrucuring-uses.patch dated July 12, 2012, I get the following error message while testing, apparently because some metadata is missing on the new functions your patch adds to core:</p> <p> <span class="error">[java]</span> Testing clojure.test-clojure.metadata<br/> <span class="error">[java]</span> <br/> <span class="error">[java]</span> FAIL in (public-vars-with-docstrings-have-added) (metadata.clj:45)<br/> <span class="error">[java]</span> expected: (= [] (remove (comp :added meta) public-vars-with-docstrin<br/> gs-not-generated))<br/> <span class="error">[java]</span> actual: (not (= [] (#'clojure.core/throw-on-varargs-and-destr #'cl<br/> ojure.core/throw-on-varargs)))</p> <p>Hi Andy, this updated patch declares the two new checking fns private which makes the tests pass again.</p> <p>Stupid mistake by me: Of course, I've tested the last version, too, but afterwards I decided it wouldn't be bad to add some docstrings, and of course, adding docstrings cannot break anything. <img class="emoticon" src="http://dev.clojure.org/jira/images/icons/emoticons/wink.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> <p>Patch applies cleanly against 4004d267e124f12b65b0d7fb6522f32a75e3c4fb. Submitter confirmed as a CA signer. </p> <p>This looks ok to me, but it seems like a fair amount of duplication to accomplish the task. It seems like we should just be able to ask if it is ok to proceed, instead of having to pick which function needs to be called in what case.</p> <p>Aaron, can you please elaborate? I don't get what you mean with duplication and asking if it is ok to proceed.</p> <p>Rebased to apply cleanly on master again.</p> <p>Pardon the silly contribution, but the added methods' usage of double-negations (when-not ...) seems unnecessary.</p> <p>Hi Victor, this revamped patch removes the double-negation and is more concise and clearer as a result. So your comment wasn't as silly as you thought. <img class="emoticon" src="http://dev.clojure.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> <p>Hey Stu, do you mind to explain why you've declined the patch?</p> <p>@Tassilo: <a href="https://groups.google.com/forum/#!topic/clojure-dev/qjkW-cv8nog">https://groups.google.com/forum/#!topic/clojure-dev/qjkW-cv8nog</a></p> <p>@Marek, Stu: Thanks, I've left a reply there: <a href="https://groups.google.com/d/msg/clojure-dev/qjkW-cv8nog/rMNFqbjNj-EJ">https://groups.google.com/d/msg/clojure-dev/qjkW-cv8nog/rMNFqbjNj-EJ</a></p> Approval Not Approved Global Rank Patch Code