[PATCH 1 of 6] extensions: import the exthelper class from evolve ff799015d62e
Matt Harbison
mharbison72 at gmail.com
Sun Dec 2 09:31:37 EST 2018
>> On Dec 2, 2018, at 6:37 AM, Yuya Nishihara <yuya at tcha.org> wrote:
>>
>> On Fri, 30 Nov 2018 23:10:55 -0500, Matt Harbison wrote:
>> # HG changeset patch
>> # User Matt Harbison <matt_harbison at yahoo.com>
>> # Date 1543121473 18000
>> # Sat Nov 24 23:51:13 2018 -0500
>> # Node ID d5a04a8016a270dce028bddb2483509e0429f113
>> # Parent 33d30fb1e4ae52a283ef487ccf5dfbe59b8a5a68
>> extensions: import the exthelper class from evolve ff799015d62e
>
>> I'm not sure what licensing info to put in place, since it wasn't available on
>> the original copy.
>
> Boris?
>
>> + def configitem(self, section, config, default=configitems.dynamicdefault):
>> + """Register a config item.
>> + """
>> + self._configitem(section, config, default=default)
>
> What's the point of reinventing the registrar functions?
>
> I understand it will be useful to provide decorators for various setup
> hooks, but we have registrar API for table registrations. And less coupled
> abstraction is generally better.
I wondered about that too. OTOH, then it’s consistent with everything else and you don’t need to add this boilerplate (which isn’t hard, but I never remember exactly what it is):
configtable = {}
configitem = registrar.configitem(configtable)
(Unless you also meant fileset/revset/template registrations shouldn’t be duplicated too.)
I wasn’t thrilled with the class name and first tried putting this in the extensions module, but I think there was a cycle. Maybe that will go away if we boil this down to just the setup functions.
More information about the Mercurial-devel
mailing list