Derick Rethans wrote:
> On Tue, 4 Dec 2007, Falko Menge wrote:
>
>> However the design with interfaces does not seem to be very elegant
>> because it would require a complete reimplementation of nearly all
>> features of the ezcReflection component in the Static Reflection
>> classes. Thus I propose a dependency injection approach:
>>
>> We could allow the injection of instances of external Reflection
>> implementations through the constructors of the ezcReflection classes.
>> Such an external Reflection implementation would have to extend the
>> PHP reflection classes as well as the ezcReflection does. If such an
>> instance is given the ezcReflection would leverage it as its data
>> source. Otherwise PHP Reflection would be utilized as usual.
>> Additional features of the external instance could also be leveraged
>> by forwarding calls via overloading.
>>
>> class ezcReflectionClass extends ReflectionClass
>> {
>> protected $class;
>>
>> /**
>> * @param string|object|ReflectionClass $argument
>> * name, instance or ReflectionClass object of
>> * the class to be reflected
>> */
>> public function __construct( $argument )
>> {
>> if ( !$argument instanceof ReflectionClass )
>> {
>> parent::__construct($argument);
>> }
>> $this->class = $argument;
>> ...
>> }
>
> We already do some form of dependency injection in some places, most
> notable where we return classes. Take for example this example from
> DatabaseSchema:
>
> http://ezcomponents.org/docs/api/trunk/DatabaseSchema/ezcDbSchema.html#setOptions
> and
> http://ezcomponents.org/docs/api/trunk/DatabaseSchema/ezcDbSchemaOptions.html
>
> or the mailClass property of the ezcMailParser:
> http://ezcomponents.org/docs/api/trunk/Mail/ezcMailParserOptions.html#prop-$mailClass
> example is:
> http://ezcomponents.org/docs/api/trunk/Mail/ezcMailParserOptions.html#prop-$mailClass
> (first example).
>
> In those cases, we don't really have to make if () statements to figure
> out which part to call, but just juse this classname. Something similar
> can be done for compatible implementations of reflection, without
> actually having to wrap it like you do above.
I studied the code of ezcMailParser and ezcDbSchema and I
also read the section about dependency injection in the
implementation guidelines. Basically the proposed solution
does the same. The only difference is that we want to keep
the inheritance relationship between PHP Reflection and
ezcReflection. Breaking the compatibility with PHP
Reflection by not extending its classes but only wrapping
them would prevent users from switching to ezcReflection if
they use type hinting.
>From a users point of view it would be the best to inherit
from PHP Reflection and provide a good documentation for the
whole component. The reimplementation of all methods
>From the implementations point of view using only delegation
to any kind of reflection instance would be less effort,
cleaner and more maintainable. The documentation issue could
in this case be solved using the @method annotation:
http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.method.pkg.html
So we have to decide whether we want maximum benefit for the
user or the cleanest possible implementation.
Kind regards
Falko
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
