[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