Added by Ralph Schindler, last edited by Ralph Schindler on Jul 02, 2008  (view change)

Labels

 
(None)

Zend Framework: Zend_Reflection Component Proposal

Proposed Component Name Zend_Reflection
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Reflection
Proposers Ralph Schindler
Zend Liaison TBD
Revision 1.0 - 24 June 2008: Initial Draft. (wiki revision: 8)

Table of Contents

1. Overview

The purpose of Zend_Reflection is to build upon and add value to the base Reflection classes in PHP. In several instances within the Zend Framework, there are cases where the base PHP Reflection classes are extended with functionality that is "missing" from their PHP counterparts. This functionality will be implemented in Zend_Reflection by extending the PHP Reflection classes. By extending the base PHP classes, this allows developers to interchangeable use both Zend_Reflection and PHP Reflection in their libraries, modules and applications.

Most immediately, this component will add the ability to Reflect PHP Files, gather Reflection contents and reflect Docblocks and their principal parts.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will extend PHP's Reflection Classes where possible.
  • This component will implement new reflectable elements not handled by PHP Reflection.
  • This component will decompose PHPDocumentor (Docblock) comments.
  • This component will not reflect non PHP code.
  • This component will standardize use cases already seen within Zend Framework, specifically with respect to Zend_Server_Reflection.
  • This component will not attempt to load unrecognized elements.

4. Dependencies on Other Framework Components

  • PHP Reflection
  • Zend_Exception

5. Theory of Operation

This component will be instantiable in the same manner that current reflectable objects are instantiated. This component can be seen as a working extension of the PHP Reflection API.

6. Milestones / Tasks

  • DONE Milestone 1: design notes will be published here
  • Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
  • Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
  • Milestone 4: Unit tests exist, work, and are checked into SVN.
  • Milestone 5: Initial documentation exists.

7. Class Index

  • Zend_Reflection_Class
  • Zend_Reflection_Docblock
  • Zend_Reflection_Docblock_Tag
  • Zend_Reflection_Docblock_Tag_Param
  • Zend_Reflection_Docblock_Tag_Return
  • Zend_Reflection_Docblock_Tag
  • Zend_Reflection_Docblock
  • Zend_Reflection_Exception
  • Zend_Reflection_Extension
  • Zend_Reflection_File
  • Zend_Reflection_Function
  • Zend_Reflection_Method
  • Zend_Reflection_Parameter
  • Zend_Reflection_Property

8. Use Cases

UC-01

UC-02
UC-03
UC-04

9. Class Skeletons

SVN LINK

API and use cases look good! It'll be good to have a standard interface for parsing the docblocks that can be used in a variety of situations (including Zend_Server components).

It would be practical to retrieve arbitrary parameters from the docblock.

Hey Lars, it is possible and I'll add the use case for that above.

As you can see, it works in this unit test:
TagTest.php Unit Test

Look for the call that pulls out the @author tag from the class docblock

-ralph

Ralph,

Looks good! I would go ahead and call it Zend_Reflection_Docblock_Tag_Parameter since you have Zend_Reflection_Parameter. Other than that, I love the idea of being able to grab the @tags in DocBlocks.

Incidentally, I'm not clear on the naming convention right now. So, for iTunes it would be "Itunes". But for DocBlock, which is camel cased, is it "Docblock" or "DocBlock"?

I was staying kinda strict to the documented elements of PHPDoc comments. The 3 fundamental peices of a docblock are defined here

  • Short description
  • Long description
  • Tags
    • These tags can further be defined by their type defined here

I chose param b/c that is the actual tag name, just like return, and any other future tags that need object representations.

I dont know the answer to the docBlock question.

It'd be nice to have full list of added-value services compared to PHP reflection. It is only Docblocks or also some other things?

Off the bat, yes,

  • Ability to Reflect a file (in PHP this should/would be ReflectionFile)
  • Ability to get content body of methods, files, functions, just as you can get docComment
  • Ability for Parameter objects to return type information from docblocks
  • more to come?