Why does this need to be part of Reflection? Seems a rather odd place for
it IMHO, since it basically hard-codes the functionality into part of the
core that's not trivially extendable (at least $class->getMethods() is hard
to override)...
Instead, what about adding a SPL class to parse the comment. Something like
class SplAnnotationParser {
const PARSE_DEFAULT = 1;
const PARSE_FUNCTION = 2;
public function __construct($rules = self::PARSE_DEFAULT);
/**
* @param string $comment The comment to parse
* @returns array An array of parsed annotations, pursuant to the
ruleset used
public function parseAnnotations($comment);
}
That way, you'd do:
$parser = new SplAnnotationParser(SplAnnotationParser::PARE_FUNCTION);
foreach ($class->getMethods() as $method) {
$annotations = $parser->parseAnnotations($method->getDocComment());
}
It decouples the implementation, and allows for people to polymorphically
substitute different parsers for different needs.
Thoughts?
I don't think it should be implemented as SPL feature since it uses the
doc-comment of a specific function. Since we got getDocComment() in the
Reflection extension, it just feel obvious for me that I'd have the
annotations accessors in the related classes too. In addition, in order to
parse a doc-block you should have either the doc-block as string or the
class/method/function etc. In case you wish to perform it from the
class/method etc. - the logic is already well-known for users that they can
reflect their classes using Reflection, so I don't see the reason to add
another layer. In case you wish to use the doc-comment - it's possible ,
but the user most likely need to initialize a Reflection object anyway to
get this doc-comment string...