bug#54802: OClosure: Make `interactive-form` a generic function

[Stefan Monnier]

>> Not sure what you mean by "affect all of Emacs".  It affects
>> a well-delimited (and small) part of the code.
> It is called outside of the advice functions.

The patch under discussion moves a well-understood and simple piece of
code from C to ELisp, and while doing so marks the resulting function as
generic so that it can be overridden on a case-by-case basis
by packages.

The move from C to ELisp should make no difference other than
performance.  As discussed with Po Lu, if needed, we can reduce this
impact at the cost of a less clean API, and I think it would be for the
worse (the result would be a more complex system with two equivalent
functions where the coders need to understand when to use which), but
I could live with that.

The fact of marking it as generic does not directly have any impact at
all (literally: it just adds a `cl--generic` property to the
`interactive-form` symbol but the content of the `symbol-function` is
the same as it would be for a normal function :-).

The act of overriding it for specific cases by added methods will on the
other hand make a difference and can introduce bugs, just like advising
`interactive-form` can introduce bugs.  It'll be the responsability of
those writing those methods.  I don't foresee this to become a problem at
all since it'll be rather uncommon to define such methods and it will
most likely be limited to OClosures (doing it for other values would be
of limited interest).

>> Are you worried about introducing bugs, about the performance impact,
>> or something else?
> All of them.

What makes you think this can introduce bugs?  What kinds of bugs?

Can you point to code where you'd expect `interactive-form` to be
a potential performance problem?

Care to be a bit more specific about the "something else"?


        Stefan