Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations

[Dmitry Gutov]

On 27.05.2021 17:19, João Távora wrote:

> I  was just suggesting that using a small
> variation of Juri's idea, the backend may want to use:
>
>     :resolution-function #'im-backend-x-and-this-is-my-gf
>
> Instead of:
>
>     :resolution-function (lambda (str field) (pcase field ...))
>
> Then, you could easily inspect the methods of
> 'im-backend-x-and-this-is-my-gf' to see what fields it supports.  The
> signature of the gf is:
>
>     (defgeneric im-backend-x-and-this-is-my-gf (str field) ...)

I was talking about detecting the lack of such support programmatically. 
At the moment we can do that with (null (plist-get ...)). With generic 
functions, one can get that by catching cl-no-applicable-method.

I was thinking the definitions in your proposal would look like

(defgeneric im-backend-resolve ((head 'some str) field)
  <the field is dispatched dynamically on>)

, but the definitions could also look like

(defgeneric im-backend-resolve ((head 'some str) (eql 'a field) str)
  <the implementation for field-a>)

(defgeneric im-backend-resolve ((head 'some str) (eql 'b field) str)
  <the implementation for field-a>)

...then we'll get the same error if the field is not implemented.

But why choose that instead of

(defgeneric im-backend-field-a ((head 'some str) str)
  <the implementation for field-a>)

(defgeneric im-backend-field-b ((head 'some str) str)
  <the implementation for field-a>)

?

> Additionally, and anticipating a possible follow-up question, to share
> information between different methods of the same GF (for performance
> reasons and only if they indeed exist) one can use a second API point
> that is called to let-bind special variables accessed with an argless
> function.  I've used this pattern successfully in CLOS many times.

Passing context info through dynamic vars?

> > Yet still, even when using generic functions, why would we create an
> > additional dispatcher mechanism when cl-generic can already do that for
> > us? To reduce the number of methods in the API description?
>
> We wouldn't.  I _am_ suggesting using cl-generic:
>
> I also tried to express that if we redesigned the method, instead of
> 'im-backend-x-and-this-is-my-gf', you could have 'this-is-the-resolution-gf'
> with a signature that takes the table (aka backend) as an argument:
>
>     (defgeneric this-is-the-resolution-gf (backend field str) ...)
>
> And if backends were CLOS object you could leverage inheritance to mix
> and match stuff between different backends.

The difference is that all combinations would need to be anticipated in 
backend definitions in advance.

Anyway, like I said, this discussion seems premature. There is little 
point in complicating the c-a-p-f API with generic functions unless we 
also use them for core functionality.