Matthieu Moy <[EMAIL PROTECTED]> writes:

>> In addition, calling the back-end function directly is _not_ the same
>> as calling the unified function; in many cases the defaults for the
>> interactive arguments are different. So using wrappers generated via
>> dvc-back-end-wrappers gives more consistent behavior.
>
> True, I didn't notice that. Well, normally, the (interactive ...)
> thing would be the same, but that's just programmer's discipline, and
> we can do better here.
>
> One way to fix that would be to remove the (interactive ...) part of
> define-dvc-unified-command, and use `call-interactively' to take the
> (interactive ...) statement of the target function.

I think that's moving in the wrong direction; it would be better to
make the back-ends _not_ interactive. But let's discuss that in
another thread.

> Another would be to keep define-dvc-unified-command as it is, but
> instead of defining <back-end>-whatever, and aliasing it to
> <back-end>-dvc-whatever, we would define <back-end>-dvc-whatever, and
> use the dvc-back-end-wrappers to define <back-end>-dvc-whatever.

I like this solution, except you meant "have dvc-back-end-wrappers to
define <back-end>-whatever" (no "dvc" in the auto-generated function).

>>> `dvc-back-end-wrappers' is only needed when an interactive function is
>>> defined with (defun dvc-<command> ...), with dvc-<command> actually
>>> doing some dispatching later on.
>>
>> And only when the corresponding function is _not_ already defined by
>> the back-end.
>
> That's two different questions. It's needed whether the function is
> defined or not in the back-end. It's nuisive (name clash) when the
> function is defined in the back-end, so the solution is to remove the
> version defined in the back-ends.

Another solution is to give the wrapper a guarranteed-unique name. But
I like cleaning up the back-ends better.

> What other solution do you propose?

I was thinking we really don't need dvc-back-end-wrappers. But I think
keeping it and cleaning up the back-ends is better.

-- 
-- Stephe

_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev

Reply via email to