[Flow] Proxyclass Building is useless imho in 90%

[Carsten Bleicker]

Am 17.11.2014 um 10:46 schrieb Karsten Dambekalns <karsten at typo3.org>:

> Hi.
> 
> On 07.11.2014, at 14:25, Carsten Bleicker <carsten at bleicker.de> wrote:
> 
>> In 90% of all classes proxy class building is not required.
> 
> While I am not sure it’s that much, there are sure more proxy class being built than needed, agreed.
> 
>> AFAIK its out of the box used f.e. in Entities to inject a flow persistence identifier.
>> But couldnt this be done by simply shipping a trait for this? wich contains the property?
> 
> Well, using traits was not an option so far, because Flow (up to 2.3) still supports PHP 5.3. Be assured that we thought about uses for traits as soon as the landed in PHP.
afaik, cms requires 5.5 as of v7? doing it this way too?
> 
>> Also its used for AOP.
>> AOP is imho this concept is used for user case scenarios.
>> So isnt it enough to enable proxy class building by usecase (if you need it)
>> and by default proxy class building is totaly disabled?
> 
> Sure we could detect AOP targets and selectively enable proxy class building.
> 
>> As i mentioned in jira, injection should work also without proxyclassbuilding.
>> So f.e. @Flow\Inject could work on original classes, not only on proxy classes.
> 
> Alright, if you have *any* idea for making this work, let us know. We didn’t find any. And this is not a try to troll you or anyone else.
arent the injections static calls to bootstap?
$reflectionService_reference = &$this->reflectionService;
if(....){
	...
	$this->reflectionService = \TYPO3\Flow\Core\Bootstrap::$staticObjectManager->createLazyDependency('foo',  $reflectionService_reference, 'TYPO3\Flow\Reflection\ReflectionService', function() {
		return \TYPO3\Flow\Core\Bootstrap::$staticObjectManager->get('TYPO3\Flow\Reflection\ReflectionService'); });
	});
}
...
couldnt this be just a part of a trait also?
so in origin class __construct(){ FlowTrait::injections() }
injections using phps \ReflectionClass() to analyze annotations what should be injected?
just as an idea. maybe its for the trash bin.

> 
>> If proxy is "must be switched on" it results in:
>> 1.) the proxyclass building time should be reduced a lot.
> 
> +1 to that.
> 
>> 2.) you can use debug breakpoints
> 
> Granted, this is cumbersome. But a simple debug_break() for the first breakpoint does wonders, and as soon as the debugger kicked in you can use IDE breakpoints as you like, because those are actually set in the proxy classes.
> 
> Another option is this proxy, although I am not sure if it works currently: https://github.com/sandstorm/debugproxy. More on that in http://sandstorm-media.de/blog/2012/08/09/debugging-flow3.html and http://techblog.b-have.de/typo3-flow-xdebug/
i tried it once, but does not get it runnig.
i cant count how often it happened, that i used xdebug_break(), phpstorm enters the proxy class and i started
editing in proxy class without noticing, that i am not in the origin. 

> 
>> 3.) you know what a class realy does without looking for maybe existing AOP magic
> 
> No, because what if it is switched on? You swap "looking for AOP magic" to “looking for AOP being turned on” in the first place ;)
> 
>> 4.) you dont run into exceptions if flow tries to build proxy for Foo extends \ArrayObject{}
> 
> Needs to be fixed anyway. Is there an issue for that?
i think its not present. But i will report it if i can reproduce it again.

> 
> 
> Regards,
> Karsten_______________________________________________
> Flow mailing list
> Flow at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/flow