The forms required for implementing arity-overloaded protocol methods are inconsistent between the "extend-*" macros and "defrecord".
The "extend" family of macros requires overloaded method definitions to follow the form used by defn:
However, "defrecord" requires implementations to be defined separately:
Furthermore, the error modes if you get it wrong are unhelpful.
If you use the "defrecord" form with "extend-*", it evals successfully, but later definitions silently overwrite lexically previous definitions.
If you use the "extend-*" form with "defrecord", it gives a cryptic error about "unsupported binding form" on the body of the method.
This is not the same issue as CLJ-1056: That pertains to the syntax for declaring a protocol, this problem is with the syntax for implementing a protocol.
All
Attached a patch for this.
For defrecord, I check which style is used for defining methods, and transform into the original style if the new style is used. For the check I do what I believe defn does, which is (vector? (first fdecl)).
For extend-*, I skip the checking, and just transform everything into the same format.
Tests included for both.
All tests pass.
What the proposal?
Comment made by: tsachev
This hit me too.
I workaround this using extend for the protocols that have multi arity methods
i.e. for the above example