[TYPO3-50-general] Improvment for Injections?!?

[Malte Jansen]

Hi Robert,

ok
it just came into my minde...
Perhaps DEV3 could add some autocompletion for injections, so you don't 
have to write so much simluar code.

Cheers,

Malte

Robert Lemke schrieb:
> Hi Malte,
> 
> Am 11.01.2009 um 19:46 schrieb Malte Jansen:
> 
>> it would be nice get some feedback...
>> Bad idea? Not possible? Perhaps later? We working on it ;) ?
> 
> sorry, forgot about this thread.
> 
>> Malte Jansen schrieb:
>>> Hi,
>>>
>>> I just tested the AOP and discovered, if you just use an aspect for
>>> injecting a class.
>>>
>>> So what about some injecting the Classes via a DocComment-Tag-Syntax?
>>> e.g.
>>> @inject $objectFactory F3::FLOW3::Object::FactoryInterface
>>> @inject property F3::MyPackage::MyClassInterface
>>>
>>> There is no autocompleting, but the outline of a class has less entries
>>> and injecting something is more or less more an AOP-aspect, than
>>> belonging to a model.
>>>
>>> And if you want to test a class, you can use the old-fashioned-syntax
>>> (implemented somehow as aspect):
>>> public function injectObjectFactory(F3::FLOW3::Object::FactoryInterface
>>> $objectFactory);
>>>
> 
> 
> Although it sounds tempting, there are a few issues with this solution:
> 
>  1. Readibility / Black Magic
> 
>     All code a class uses internally should actually be found in the class
>     itself (or one of the parent classes). It would be too much magic if
>     the class code referred to $this->objectFactory but there is no such
>     property defined and no method which fills that property.
> 
>     Cross-cutting concerns, which are extracted by AOP, are a different 
> thing:
>     Although they introduce new functionality, the target class does not 
> refer
>     to it - it doesn't even know about it.
> 
>     Although it could be argued that annotations are well enough 
> readable for
>     this mechanism, injection of dependencies is simply not a cross-cutting
>     concern but an important part of the class construction.
> 
>  2. Loss of contract
> 
>     No matter if your class implements an interface or not, third party 
> code
>     will rely on the set of public functions your class provides. If this
>     code wants to call an inject method (or a regular setter), it doesn't
>     know for sure if it exists.
> 
>  3. Testing
> 
>     Most importantly, tests should always work without the AOP 
> framework, because
>     only this guarantees that you're testing the code you want (and not 
> the woven-in
>     functionality). You write:
> 
>>> And if you want to test a class, you can use the old-fashioned-syntax
> 
>     You always want to test a class of course, therefore you always 
> would have to
>     use the old-fashioned syntax.
> 
> The basic idea you had is not wrong though, it surely would be nice to 
> simplify
> setter injection. A cleaner but still not clean approach would be to 
> declare
> public properties which are then automatically filled from outside:
> 
>    /**
>     * @var F3\FLOW3\Object\Factory\Interface
>     */
>    public $objectFactory;
> 
> But I never really liked that solution because it conflicts with our 
> rule of not
> having public properties at all.
> 
> So, I'd say, for the time being it's nothing I'd like to see support for 
> in FLOW3.
> 
> Cheers,
> robert