Protocol implementation inconsistencies when overloading arity

Description

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.

Environment

All

Activity

Show:
Paavo Parkkinen
November 17, 2013, 12:02 PM

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.

Rich Hickey
June 10, 2014, 5:00 PM

What the proposal?

import
August 16, 2018, 3:15 PM

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

Assignee

Unassigned

Reporter

import

Labels

Approval

Triaged

Patch

Code and Test

Affects versions

Priority

Major