Excerpts from Augie Fackler's message of 2017-03-21 15:11:26 -0400:
> (bah, sorry for dropping the list)
>
> On Tue, Mar 21, 2017 at 3:05 PM, Jun Wu <qu...@fb.com> wrote:
> >>
> >> Would it make more sense to have a "request" or "invocation" object that
> >> has a ui (and then, eventually, transitively has a config)?
> >
> > I'm not sure if I follow. The problem is that extensions only have "ui",
> > they do not have the "request" object. If they have, then the problem is
> > solved.
> >
> > If we add "ui.req", it's not better than "ui.args".
> >
> > If we "incrementally" replace "ui" with "req" everywhere, it's a huge
> > amount of work with all kinds of BC issues.
>
> I feel obligated to remind you that we don't offer any stability
> promises on internals, so if this is a righteous cleanup (using req or
> similar instead of ui), it's probably worth doing in any case.
I know. In theory we can also drop "extsetup" and only keep "uisetup", or
drop the support for "extsetup()" without the ui argument. But I guess we
didn't do that for a reason.
> Note that we're coming up on an interesting moment when we'll know
> extensions required significant cleanup anyway (python 3), so we might
> want to evaluate other internal structure cleanups while we're
> breaking everyone anyway.
Even if we have done replacing "ui" with "req" everywhere, I don't think
that's better - the request object practically becomes the new "ui" object
with all kinds of features.
If I guessed correctly, what you want is a new layer inserted, like:
We have a "root" object. "root" could be either "ui" or "request".
To access configs, use: root.config.get, root.config.set, and there is
no root.setconfig.
To access I/O related features, use: root.io.fin, root.io.fout, ...,
there is no root.fin.
Just split ui functions to subobjects.
My point is the "root" object does not have to be "request". It can be done
using the "ui" object incrementally, using a similar approach like what we
did for "repo.join -> repo.vfs.join". It's more realistic.
Anyway, the long-term refactoring shouldn't block this simple patch. And I
think it's reasonable to add "ui.args" for now.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
