We could have:
It would my life a lot easier....
Value objects can come in two forms:
a) as embedded value objects
b) as collections of value objects
An implementation should concentrate on a) first. The following things all concentrate on a).
1. "select f from Foo f where f.embedded.value = ?1" (setParameter(1, $scalarValue))
2. "select f from Foo f where f.embedded = ?1" (setParameter(1, $embeddedValueObject))
At least Nr.1 must be possible in a first implementation.
1. "select f from Foo f" must explode embedded value objects in the SQL SELECT clause.
2. "select f.embedded from Foo f" must explode the columns of the embedded object in the SQL SELECT clause.
At least Nr. 1 must be possible in a first implementation, obviously.
Components affected (among others): Parser, SqlWalker, ...
The persisters need to take embedded value objects into account when persisting as well as loading entities.
Components affected (among others): Persisters, UnitOfWork, ...
ClassMetadataInfo needs to be extended with a field (probably an array) that contains the mappings of embedded values.
New annotations as well as XML/YAML elements are needed.
Components affected (among others): ClassMetadataInfo, AnnotationDriver, YamlDriver, XmlDriver, doctrine-mapping.xsd, ...
If value objects are supposed to be immutable this is easy and might require no or few changes. If, however, we want to track changes in mutable value objects it might get more complicated.
Components affected (among others): UnitOfWork, ...