[DCOM-96] ProxyFactory logic moved to doctrine common

[Ocramius]

Initial requirements

1. Common proxy generation for:
   • ORM
   • MongoDB ODM
   • CouchDB ODM
   • PHPCR ODM
2. Generic implementation of proxies: it is now possible to proxy any object as long as a ClassMetadata definition is provided
3. Public properties lazy loading (yes we can!)

Sample Proxy

See this example generated proxy class

Public properties lazy loading

Public properties lazy loading has been implemented, and I've opened php/php-src#228 to protect the trick discovered by @lsmith77.

Mapped public fields and associations will trigger lazy loading through __get, __set and __isset.

Transient properties and identifier fields won't trigger lazy loading. Same applies for simple identifier getters (as was already happening in ORM since 2.2). I've used the ClassMetadata interface to determine fields and associations to lazy load.

New Proxy interface (not a BC Break)

interface Proxy
{
    const MARKER = '__CG__';
    const MARKER_LENGTH = 6;
    public function __load();
    public function __isInitialized();
    public function __setInitialized($initialized);
    public function __setInitializer(Closure $initializer = null);
    public function __getInitializer();
    public function __setCloner(Closure $cloner = null);
    public function __getCloner();
    public function __getLazyProperties(); // retrieves default properties values - useful when restoring properties
}

Lazy loading via closures

I came up with the idea of using closures to lazy load proxies. This allows removal of any reference to the OjectManager, and makes it possible to dump Proxy objects as long as there are not circular references between them (XDebug solves this).

The default constructor as of the current proxy generator implementation has following signature:

public function __construct(Closure $initializer = null, Closure $cloner = null);

When used by the Proxy, the initializer will be called with object itself as first parameter, the called method name (the one that triggered lazy loading) as second parameter and the parameters that were passed to that method as third parameter.

This allows any of the current implementation to define an initialization logic (even outside the scope of persistence), and to eventually define some finer grained logic to be dispatched for LOB fields or getters/setters.

Proxy generation

Generating a proxy requires that a valid instance of Doctrine\Common\Persistence\Mapping\ClassMetadata is passed to the Doctrine\Common\Proxy\ProxyGenerator. A proxy namespace and a proxy directory are also required to build the ProxyGenerator itself.

The generator uses a template and a list of placeholders mapped to either strings or callables. Those placeholders are used in the template while generating the Proxy class. Every callable mapped as a placeholder is called with the class metadata as first parameter. This should allow some fine-grained customization when the defaults of the proxy generator are not enough.

Autoloading

Autoloader for proxies has been simply copied from the ORM.

Testing

I tested each case that I could come up with. I need suggestions on edge cases that should be documented (like above, when I mentioned setting public properties and the PHP bug).

Directions for MongoDB ODM/PHPCR implementors

I've opened following related PRs:

• [DCOM-96] Moving proxy generation and autoloading to common orm#406
• [DCOM-96] proxy generation as of doctrine/common#168 phpcr-odm#187
• [DCOM-96] proxy generation as of doctrine/common#168 mongodb-odm#445
• [DCOM-96] proxy generation as of doctrine/common#168 couchdb-odm#52

Performance

• When having identifier fields being private or protected, the proxy factory is twice as fast in instantiating a proxy compared to before (proxy factory to be seen in [DCOM-96] Moving proxy generation and autoloading to common orm#406)
• When having identifier fields being public, the proxy factory is twice as slow in instantiating a proxy compared to before. Hydration is also slower on public properties. This can be fixed by excluding the identifier fields from being associated to a Doctrine\Common\Reflection\RuntimePublicReflectionProperty, which is a workaround for PHP Bug 63463. It could also be possible to speed up hydration of proxies by using bulk reflection operation.

That said, allover performance and memory usage is kept almost at same levels (sometimes even faster), but the new feature is introduced.

[schmittjoh]

Just curious, have you thought about using my cg-library? This should allow you to save a lot of code.

I'm using it for generating all sorts of proxies in Symfony2.

[Ocramius]

@schmittjoh never tried it, but I don't know if we can include it here as a dependency...

[stof]

@beberlei's goal is to replace the code generation in Doctrine to use https://github.com/beberlei/DoctrineCodeGenerator so it could probably be used for proxies too

[stof]

CS issue :)

[Ocramius]

@stof not sure it should be achieved immediately, but yes, that would be a nice one :)

[stof]

please remove the _. It was part of the doctrine1 CS (used for the early development of doctrine2 too) but not of the current ones anymore (new code does not use it anymore, and private methods are renamed when the code is modified in existing classes.

[stof]

@Ocramius my link to the CodeGenerator was mainly a reply to the CG suggestion

[lsmith77]

like i said on IRC yesterday .. i would really like to retain the ability to map public properties:
https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/Proxy/ProxyFactory.php#L366

[beberlei]

Onl

Am 22.07.2012 um 02:00 schrieb Christophe [email protected]:

@beberlei's goal is to replace the code generation in Doctrine to use https://github.com/beberlei/DoctrineCodeGenerator so it could probably be used for proxies too

---

Reply to this email directly or view it on GitHub:
#168 (comment)

[beberlei]

Only userland code generation, not our own.

Am 22.07.2012 um 02:00 schrieb Christophe [email protected]:

@beberlei's goal is to replace the code generation in Doctrine to use https://github.com/beberlei/DoctrineCodeGenerator so it could probably be used for proxies too

---

Reply to this email directly or view it on GitHub:
#168 (comment)

[Ocramius]

@lsmith77 I am quite against public properties myself in my entities. Having __set (and it's siblings in the PHP docs) implemented by default would be wrong in my use case. Anyway, I'm thinking of allowing to override the template set in the generator, which would add a nice degree of flexibility.
Also it is quite unclear how this public properties mapping would be achieved, but I'm pinging you on IRC for that :)

[guilhermeblanco]

Missing spaces around the last .

[Ocramius]

@guilhermeblanco could you check this one and the related PRs so that I can remove all the references to my forks? :)

[guilhermeblanco]

Align = signs

[guilhermeblanco]

I added a few comments at the end.
Please update the remaining elements and I'm fine with merge! =)

[Ocramius]

@guilhermeblanco merge

[cordoval]