Here are my comments on the Extended Reflection API Design Document (revision from May 4th 2007).
- As discussed with Derick, I only give feedback on the Extended
Reflection API part of the proposal (CodeAnalyzer and WSDL/SOAP are
excluded).
- I like the design (it is almost the same of the Reflection_Annotation
PEAR package I started a couple of years ago, so I am biased, of
course :-) of the Extended Reflection API component and see no flaw
in it.
- The current implementation [1] looks good, too.
- Of course the class names etc. need to be changed to the ones used
in the design document (ezcReflectionClass, ...) and the CS needs
to be adapted. But those are minor issues.
- I strongly suggest, though, that we use Tobias' annotation parser
[2] and integrate it into ezcReflection.
- Getting Tobias' component into the eZ Components as a separate
Annotation component as he suggested would not work as the
Reflection component would need to depend on it which is against
our rules.
The next step in getting the Reflection component into the eZ Components
would be to transform Section 2 of your paper into a design document
that is formatting according to our guidelines. If you want, I can
help you with that.
Out of curiosity: One of the use cases mentioned for the CodeAnalyzer
component is software metrics. Have metrics (such as McCabe, for
instance) already been implemented? I am asking because this is a
topic that is getting more and more important in the PHP world and
several people are working on solutions.
--
[1] http://instantsvc.toolslave.net/trac/browser/trunk/libs/reflection
[2] http://www.schlitt.info/ez/Annotation-1.0.0alpha1.tar.bz2
--
Sebastian Bergmann
System Developer
[EMAIL PROTECTED] | eZ Systems | http://ez.no
signature.asc
Description: OpenPGP digital signature
-- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
