[PATCH 1 of 6 events v3] util: add event handling mechanism

[Pierre-Yves David]

On 09/28/2014 02:14 PM, Gregory Szorc wrote:
> On 9/28/2014 2:01 PM, Gregory Szorc wrote:
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc at gmail.com>
>> # Date 1411933407 25200
>> #      Sun Sep 28 12:43:27 2014 -0700
>> # Node ID d513c232aeba16137b291456536adee0d88a040f
>> # Parent  4109cc16279ef0e04dc70e7f4c9ab7415e6a22d3
>> util: add event handling mechanism
>>
>> The patch adds a generic event handling mechanism to Mercurial. From a
>> high level, you create a class with methods corresponding to event
>> names. You can then register functions/callbacks against events that
>> get called when that event fires.
>
> I talked with mpm about this feature at the Munich sprint and I believe
> this patch series incorporates the improvements he was looking for.
> Namely, the .register() bit was replaced by standalone classes holding
> event definitions in a more Pythonic way. mpm and I discussed using
> decorators. However, I believe __new__ (as implemented) fits the bill
> just fine.

I've walked on the __new__ path in the past (well with metaclass, but 
this is all the same) and I'm really not eager to go down that road in 
Mercurial. Decorator should be just fine.


> There is one feature notably absent from this patch series:
> documentation. I'd like to automatically generate documentation for all
> available events so extension authors have something that isn't raw
> source code to consult. However, I'm not sure where to put this. I don't
> think `hg help` is appropriate since events aren't user facing. `hg
> debugevents` perhaps?

+1 on forcing event to be declared and documented

> If incorporated, this patch series could make refactors to facilitate
> monkeypatching a thing of the past, as events can satisfy many of the
> use cases where monkeypatching was needed. As a recent example, Mike
> Hommey's recent refactorings to facilitate additional bundle2 part
> handling could likely have been avoided if bundle2 event support were
> present. This patch series should thus likely result in less code churn
> and thus increased code comprehension.

Does not apply for the bundle2 thing Mike did. In this case it is 
actually required to wrap//override existing functon to achieve a goal.

-- 
Pierre-Yves David