Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> > I was under the impression that Eli's concern was with the effect of
>> > the b-c-f change itself, not with bugs that might be introduced by
>> > the change.
>> I can't speak for Eli, but at least that's not my worry.
> I actually don't understand the difference: how is "the effect of the
> change itself" different from "bugs that might be introduced" by it.
> Sounds like the latter is a subset of the former?

The request is to change the way b-c-f and a-c-f are run such that
they're always exactly paired.  Any patch which implements such a change
could have any number of other impacts.  So we can divide the impacts of such
a patch into 2 parts:
- the part which changes b-c-f and a-c-f to be exactly paired.
- the rest.

I think the first part should be 100% safe, because any code which works
correctly with the current looser behavior of b/a-c-f should also work
correctly with the tighter behavior.  Of course, there might be code out
there which relies on the details of the current behavior b/a-c-f, but
I'm not worried about that at all.

"The rest" is the more likely source of worry.


        Stefan