check-webkit-style: Rename CppProcessor to CppChecker, etc

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Chris Jerdonek]

This change is to rename "processor" to "checker" in the context of CarriageReturnProcessors, CppProcessors, PythonProcessors, and TextProcessors, etc.

This is because we want to reserve the word "Processor" for classes that sub-class webkit.style.checker.ProcessorBase (e.g. StyleProcessor).  In this sense, "processor" is a higher-level notion than "checker" because a processor can be used for any sort of operation on file lines and not just checking style.

This distinction will be useful going forward if we want to start doing other types of operations on files aside from simply checking style (e.g. extracting license texts and modifying style, etc).

[Chris Jerdonek]

Note that this naming change was already started in--

https://bugs.webkit.org/show_bug.cgi?id=38122 (renamed processors/ folder to checkers/)
https://bugs.webkit.org/show_bug.cgi?id=37066 (create new StyleProcessor class)

[Chris Jerdonek]

Created attachment 54564 [details]
Proposed patch

No logic changes in this patch -- only renames (many using grep).

[Chris Jerdonek]

Can anyone take a look at this?  There really are no changes aside from renames.  Thanks.

[Eric Seidel (no email)]

Comment on attachment 54564 [details]
Proposed patch

I'm not sure I really understand the distinction, so all you really get is a rubber-stamp.  Why changing all this to checker, instead of the other way around?  Seems processor is about as meaningless as checker so I would probably optimize for minimal renames.

But honestly, I have really no opinions about any of this.

Do we have any need to be able to merge any of this code with anyone?

[Chris Jerdonek]

(In reply to comment #4)

Thanks, Eric.

> (From update of attachment 54564 [details])
> I'm not sure I really understand the distinction, so all you really get is a
> rubber-stamp.  Why changing all this to checker, instead of the other way
> around?  Seems processor is about as meaningless as checker so I would probably
> optimize for minimal renames.

In a nutshell, check-webkit-style uses a ProcessorBase class which can be used for any operations on files (e.g. operations other than "checking," like extracting license texts for bug 35465).

CppProcessor, PythonProcessor, etc. do not inherit from ProcessorBase, so I wanted to choose a more specific name.  Since those classes are limited to checking style, *Checker made sense.

> Do we have any need to be able to merge any of this code with anyone?

Not to my knowledge.

[Eric Seidel (no email)]

Thanks for the update.

[Chris Jerdonek]

(In reply to comment #5)
> > I'm not sure I really understand the distinction, so all you really get is a
> > rubber-stamp.  Why changing all this to checker, instead of the other way
> > around?  Seems processor is about as meaningless as checker so I would probably
> > optimize for minimal renames.
> 
> In a nutshell, check-webkit-style uses a ProcessorBase class which can be used
> for any operations on files (e.g. operations other than "checking," like
> extracting license texts for bug 35465).
> 
> CppProcessor, PythonProcessor, etc. do not inherit from ProcessorBase, so I
> wanted to choose a more specific name.  Since those classes are limited to
> checking style, *Checker made sense.

A final bit of information:

The StyleProcessor class is the class that check-webkit-style uses that does inherit from ProcessorBase.  Internally it does various things including choosing which *Checkers to construct (CarriageReturnChecker, PythonChecker, etc) and calling those.

[Chris Jerdonek]

Comment on attachment 54564 [details]
Proposed patch

Clearing flags on attachment: 54564

Committed r58742: <http://trac.webkit.org/changeset/58742>

[Chris Jerdonek]

All reviewed patches have been landed.  Closing bug.