Allow multiple patches for the same function

[PythonNut]

Presently, if you patch a single function multiple times, the definitions will work, but el-patch will be unable to validate any but the most recent patch. Ideally we would have a way to distinguish multiple patches to the same function.

One use-case for this when one version of a function is intended to be used before its file is loaded and a different version is to be used after.

[raxod502]

Does anybody have a good idea about the user interface for this?

One option would be to have a dynamic variable that one could bind, defaulting to nil, around a definition. Then patches defined with different values for that variable would be distinguishable. We could even make the use-package integration bind this variable by default to different values in the :init/el-patch and :config/el-patch blocks, thus solving the most common use case without the need for your configuration to change.

Thoughts?

[ghost]

In my opinion, multiple patches to the same function does not make sense. At that point what you have is one patched function, which is still used internally wherever it has been used and a new function you want to use explicitly. Swapping its definition before and after module reloads seems extremely hack-y and error-prone.

[raxod502]

one patched function, which is still used internally wherever it has been used

Can you elaborate? Unless some code explicitly extracts the return value of (symbol-function 'the-patched-function) and saves it, updating the patch will also update all callers unconditionally, which seems straightforward enough to me as a set of semantics.

[ghost]

Yes, and that is the purpose of this package from what I understand. Not making symbols/defuns have different meanings at different points in time?

[raxod502]

It's a package for future-proofing the operation of overriding the implementation of a function. Sometimes, one wants to override the implementation of a function to different values at different points in time. el-patch can future-proof this operation too.

[ghost]

Fair enough. You may also want to add support for temporal logical operations while at it.