Class declarations in comments are treated as real by ManifestBuilder

[mrickerby]

When class declarations that inherit from DataObject are declared in comments, ManifestBuilder::parse_file will treat it as a real class, and db/build will break when it discovers the class doesn't actually exist.

eg: the following example comment will break db/build:

/**
 *
 * <example>
 * class MyCustomClass extends DataObject {
 *    static $db = array();
 * }
 * </example>
 *
 */

[sminnee]

The dark side of parsing the the PHP files without using the PHP interpreter. :-P

Perhaps we should make use of the PHP tokenizer in ManifestBuilder? instead?

[sminnee]

An alternative solution to this problem, which might be easier/quicker than invoking the PHP tokenizer, would be to strip out comments and strings from the file's content before searching for classes.

It would be good if we could profile execution speed and memory usage of the manifest builder when choosing which implementation to go with.

[sminnee]

This is done. I went with the latter option, in the interests of implementation speed - see r52246.

[sminnee]

This wound up being a lot more complex than originally supposed. The current implementation in trunk uses the PHP tokeniser and a regular-expression-like parser that acts on tokens rather than characters.

It produces very valid results, but it's very slow (about 10 seconds on my macbook to parse all files). As a consequence, I've resorted to caching the parse results of each file, and only reparses files that have actually changed. This means that it's nice and fast, but I'm concerned about adding more caching, considering that SilverStripe? already caches a lot.

The changes are in r52327. Do we want to stick with this implementation, or should we go back to the drawing board?

[sharvey]

We ran into the same problem on #2398