If $this->comments is EXTRA_LAZY, then this code will always produce SQL query to database and always will work fine. But if it is not EXTRA_LAZY and appears to be loaded before (for eample count($this->comments) was called before), then this code will produce error "Trying to get private property Comment::$new from ClosureExpressionVisitor context".

I thins we should have something like reflection or \Closure::bind() stuff to get actual field value within ClosureExpressionVisitor regardless this field is private or public.

I know I can create getter getNew() or isNew(), but I believe this is known to be a good OOP practice to avoid unnecessary getters, and I am not sure collection api should make this decision for me.

haha I really want to create PR for it, but I'm just curious how we are going to test this on multiple PHP versions? Because isVariadic only works in PHP 5.6. Do the ProxyGenerator tests compare the output of the generated PHP scripts?

Currently, aside from the "NOTIFY" change tracking policy which takes long to implement on pre-existing entities, there is no atomic mechanism to allow tracking changes that take place inside de-serialized values of the DBAL\ObjectType once the entity has been loaded.

The UnitOfWork uses PHP's identity comparison operator (===) to compute the changed sets which yelds no change result when comparing pointers to the same object instance.

By implementing this interface, a serialized object may manage it's own dirty state and ensure the new values are persisted without affecting the entity's current change tracking policy.

The corresponding pull request on doctrine2 changes the following in Doctrine\ORM\UnitOfWork.php:
// skip if value haven't changed
if ($orgValue === $actualValue)

All doctrine projects implements events. A lot of them are similars, but there is no base class defining common Events.

I tried to gathen them all in this PR. I looked into ```CouchDb-orm```, ```doctrine-orm```, ```doctrine-mongodb-odm``` and ```phpcr-odm```.

I only added events present in all packages, but CouchDB is the only one to not implement some events implemented in every other packages (```postPersist```, ```loadClassmetadata```, ```preFlush```, etc.).

In the case of an empty array stored, the result of casting an empty array is false but actually there's a value in cache with they key $id. As a matter of fact, when you take a look at MemcachedCache cache provider class, the doContains method looks like this:

I see. It would be nice if the API docs were crosslinked, so the list of namespaces in the left column is complete, and so that references to classes in other projects were links (this is also an issue with e.g. Doctrine classes that inherit from classes in Common).

1. Add a lazy-loading implementation as we discussed on IRC already (helpful for keeping the overhead of post generation schema listener down for example)
2. Providing better debugging information of what is going on (which listeners have been called for which event, similar to Symfony2's event dispatcher)

Marijn Huizendveld sure (like... 1 year later!)
DOM2 Events ( http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/ )
The idea is to create an event system where you can control the flow over the listeners, such as prevent the default operation or stop propagation.
I'm a big fan of this because that way any piece can be easily decoupled from the base system and become a specialized event if needed. It also can be controlled depending on the conditions to be introspected by an specific listener.

Currently we have tons of code in the ODM/ORMs regarding code generation that are ugly to extend and maintain. We should extract all them into a new component, for example named: doctrine-code-generator

It should be feed by only instances of Doctrine\Common\Persistence\Mapping\ObjectMetadata into a twig template.

A base template for an entity/document is shipped

Maybe ORM/ODM specific child templates or twig traits are necessary to handle writing annotations. This could also be done by adding hooks into the code-generation somehow.

Each entity of the user can provide its own template, for examples from a configurable directory "code_templates/Vendor.ProjectBundle.Entity.User.twig" to extend the base template and add own code.

As a perspective we should aim for 5.4 generating a trait so that you can have your entity "class User
{ use UserBase; }