Refactor parser Checkpoints.
Why this is better: 1) Not needing an extra template parameter for Checkpoints ctors. This was especially confusing since the template parameter was named Parser and Parser is also used as a type name and is also a concrete type. This CL makes it clear that ParserTraits::Checkpoint is consturcted with ParserBase<ParserTraits> - that's the only sensemaking type for the ctor param anyway. 2) This CL makes ParserBase define a Checkpoint base class (which knows how to create and restore a checkpoint with ParserBase) which PreParserTraits::Checkpoint and ParserTraits::Checkpoint inherit, and not the other way around. This is a more intuitive way to implement the "base functionality + extending it" concept than the previous solution. The previous solution was to allow Traits to define a Checkpoint class and make ParserBase<Traits>::ParserCheckpoint (which defines the base functionality) inherit from it. 3) This CL moves the Checkpoint class definitions out of the SomeTraits::Type struct; SomeTraits::Type is supposed to be a collection of typedefs and not contain anything else. Checkpoints were introduced in r22925 ( https://codereview.chromium.org/443903003 ). BUG= R=wingo@igalia.com Review URL: https://codereview.chromium.org/485473004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23266 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Showing
Please
register
or
sign in
to comment