Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

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

Attachments

2

Activity

Show:

import August 16, 2018 at 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

Rich Hickey June 10, 2014 at 5:00 PM

What the proposal?

Former user November 17, 2013 at 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.

Details

Assignee

Reporter

Labels

Approval

Triaged

Patch

Code and Test

Priority

Affects versions

Created August 8, 2011 at 6:35 PM
Updated August 16, 2018 at 3:16 PM