[CLJ-825] Protocol implementation inconsistencies when overloading arity Created: 08/Aug/11 Updated: 10/Jun/14
|Affects Version/s:||Release 1.2, Release 1.3, Release 1.4, Release 1.5|
|Patch:||Code and Test|
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
|Comment by Paavo Parkkinen [ 17/Nov/13 6:02 AM ]|
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.
|Comment by Rich Hickey [ 10/Jun/14 11:00 AM ]|
What the proposal?