Matthieu Moy <[EMAIL PROTECTED]> writes: > Stephen Leake <[EMAIL PROTECTED]> writes: > >> Do we have a use case where a back-end needs to override dvc-status >> (or dvc-diff) _entirely_? > > I don't have a particular use-case in mind. xmtn might be one, but I > didn't look enough to tell.
I would certainly include xmtn in the set of "must not be special case" back-ends. > The way we manage nested for tla/baz could qualify as a use-case for > that, but it would probably be better to extend it to other back-ends > than making it a special-case of tla. Right. >> I don't see how it could both allow (total) back-end re-implementation, >> _and_ reduce duplicated code; they are conflicting goals. > > Roughly (incomplete, untested), > > (define-dvc-unified-command dvc-status > ...) > > (defun dvc-dvc-status > <whatever you'd have put in dvc-status>) I think you are suggesting that dvc-status would be "double-dispatching"; once at the top level, to allow total overriding, and then again at the finer-grained lower levels, as I proposed. That does make sense. > But as I said, if you go for your solution, we can migrate to my > solution later, if needed. So, there's not much difference Right. Ok, I'll make a stab at refactoring dvc-status in this way, in my experimental dvc-fileinfo branch. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
