[PATCH] histedit: do not check experimental.histediting in extsetup

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Mar 10 12:17:20 EST 2016



On 03/10/2016 05:11 PM, Jun Wu wrote:
> On 03/10/2016 04:43 PM, Pierre-Yves David wrote:
>> could we stick this in the histedit state?
>>
>> 1) the state is already passed around
>> 2) If you start as ng, you need to keep being ng anyway.
>
> The histeditstate is actually relying on the filesystem, which I think is
> even worse than the top-level module variables.

But the filesystem bit are relative to a single repository that we lock.

>> We could gathers them into an "actions" variable
>
> But where do you put the "actions" variable?
> If it is still a top-level module variable, I don't think the change is
> worthwhile.
> If it is to add a new parameter to every functions. As I said, it is a
> huge because a lot of functions are involved, and consider about how
> could other extensions add histedit actions.

My bottom line is:
   Don't use global variable for anything else than constant. I'm open 
to a lot of solution as long as they pass the "no global variable" check.


>
>> Given that the current code is using global variable to communication
>> data
>> between functions in the stacks I've an hard time to believe we can't
>> do better
>
> I assume you want to put "actions" (or whatever it called) to every
> functions.

Either explicitly passign actions, or attaching them to the state 
object. Or adding the necessary bit to the state object or anything else 
not involving global variable.

> I will argue the current design is actually "better":
> 1) Flexible (important)
>     3rd extension can add histedit actions, which can be a deal breaker.
>     For example, I can add an action called "spellcheck" to filter the
> message
>     to a spellchecker and apply the result.

We don't need to sacrifice extensible when moving away from global 
variable, there is a bunch of place that don't in the code (eg: 
capabilities)

> 2) Short.
>     The code is shorter and therefore needs less time to read (and write).

Global variables does not help code readability. Communicating data 
through global variables is plain bad.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list