Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: ORM
-
Security Level: All
-
Labels:None
Description
Currently, Doctrine REQUIRES that a given entity class have protected or private members explicitly defined in the class (even if meta data mapping is handled elsewhere, such as in YAML). This is less than optimal...for example, many class implementations prefer to store all data in a protected $fields member, as an array, accessing the members with getters and setters.
Doctrine makes this behavior impossible. An exception is thrown if a field defined in meta data is not an explicit member of the class. Instead, it should 'take the meta data's word for it' that the field exists, and is accessible via getters and setters, without explicitly checking for the member. The meta data is already the authoritative source, I don't see why the double check should (or needs to) be performed (although I am not familiar with Doctrine internals). Since Doctrine recommends making members private, I have to assume it is already hydrating them with the get/set accessors anyway...so it should just rely on them.
Quick example use case (notice 'name' is not actually a member...it is stored in $fields and assume meta data is defined in a separate yaml file):
class User
{ protected $fields = array(); public function getName() { return $this->fields['name']; } public function setName($name) { $this->fields['name'] = $name; } }
This maybe a potential optimization for a very future version. However currently we heavily rely on the Reflection support for properties, which kind of makes a change of this a very complex undertaking.