Is extsetup() needed?
Martin Geisler
mg at lazybytes.net
Thu Oct 22 21:23:54 UTC 2009
Yuya Nishihara <yuya at tcha.org> writes:
> Martin Geisler wrote:
>>
>> 1. load extensions
>> 2. uisetup -- wrap core Mercurial commands
>> 3. extsetup -- wrap functions in other extensions
>> 4. cmdtable
>> 5. reposetup -- fiddle with repository
>>
>> I think that should work, as long as no two extensions want to wrap
>> each others functions.
>
> Though it's unclear for me why we need to wrap extension's functions
> after wrapping core's, maybe I got understood the meaning of the
> previous message:
>
> 2. uisetup -- fix own cmdtable if any
> 3. extsetup -- wrap cmdtable of another extension and never modify own
> cmdtable
>
> is this okay?
Yes, that is what I meant. The idea is that extension A can add things
to its own cmdtable in A.uisetup so that B can always find it in
B.extsetup. If A would add more stuff in A.extsetup, then B might or
might not see it depending on the load order.
> and if it's correct, how about the following?
>
> 2. uisetup -- fix own cmdtable
> 3. cmdtable -- load ext.cmdtable to commands.table
> 4. extsetup -- wrap commands.table
>
> this can force modification of cmdtable at uisetup.
I'm afraid I don't understand why you propose this change --- is it
because you feel it simplifies the logic?
I might have forgotten an old argument in the discussion, but I think it
works okay now that we have the load-in-phases code in place. I suggest
we leave it as it is at the moment. This API is for third-party tools,
so we should not change it too often :-)
--
Martin Geisler
VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20091022/24674691/attachment.asc>
More information about the Mercurial-devel
mailing list