Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Jul 4, 2007, David Edelsohn <[EMAIL PROTECTED]> wrote: > >>>>>>> Alexandre Oliva writes: > Alexandre> It's as mechanical as the change you proposed, except that yours > Alexandre> potentially loses information that would enable someone to recover > Alexandre> !BEFORE_RELOAD_P() out of the expanded version of no_new_pseudos. > >> Except that no_new_pseudos was not used consistently. > > I'm not sure what you mean by "consistently", but regardless, how > could any argument possibly make it better to replace it with > > (reload_in_progress || reload_completed) > > rather than > > !BEFORE_RELOAD_P() > > such that anyone willing to clean things up from this point on may > have to use complex grep patters to account for ongoing line breaks, > reformatting and any other boolean transformations, just because it > had to be expanded right away rather than retained as a macro? > > What I'm proposing is just that, instead of > > s/no_new_pseudos/(reload_in_progress || reload_completed)/g > > we use > > s/no_new_pseudos/!BEFORE_RELOAD_P ()/ > > or at least keep no_new_pseudos as a macro that can be easily grepped > for and doesn't break line length limits in current sources. > > I'm not asking for any actual cleanups to be reverted, just that we > don't make it even harder to further clean it up. If taking out one > of these three variables is good, taking out another of them is going > to be better, right? Making it harder (or, more accurately, uglier) > to do so isn't helping.
For the record, Alex puts my point of view perfectly here too. I gather from the follow-ups that there's resistance to s/no_new_pseudos/!BEFORE_RELOAD_P ()/ -- with BEFORE_RELOAD_P defined as "reload_in_progress || reload_completed" until Alex's follow-on change is implemented -- but I don't understand why. Richard
