2013/5/1 Rasmus Schultz <ras...@mindplay.dk> > > One could > > write a PropertyReference class right now with literally the only > > difference being the lack of a builtin operator (ie new > > PropertyReference($obj, 'prop') versus ^$obj->prop): the fact that > > nobody seems to have done this in a major framework I know of suggests > > that there isn't a strong need for encapsulating the indirection > > beyond the $obj->$prop syntax that's worked forever. > > > > Look at the Symfony form-builder example - encapsulating the indirection is > *precisely* what they're doing: the object reference is stored in the > form-builder, and property-names are added subsequently. >
As the developer of the Symfony Form component, I would like to clarify that this is not true. At the time the property reference is stored, the object it refers to is not (necessarily) known. You could build an abstract form definition for "Author" instances, but only later instantiate a form for that definition with a concrete object. So to be really useful in a form context, property references need to be separated from object instances (something like "^Author::$firstName" could work). Second, it is important that references can span multiple nodes in an object/array graph. In Symfony, we built the PropertyAccess component for that [1] which allows references like "authors[0].personalDetails[firstName]" which translates to ->getAuthors()[0]->getPersonalDetails()['firstName'] or ->authors[0]->getPersonalDetails()['firstName'] etc., depending on whether accessors exist or the properties themselves are public (also works for writing values). This is a concept borrowed from Java and known as "property paths". [2] Without the possibility of chaining, property references are useless IMO. Cheers, Bernhard [1] http://symfony.com/doc/current/components/property_access/introduction.html [2] http://static.springsource.org/spring-data/data-commons/docs/1.3.0.M1/api/org/springframework/data/mapping/PropertyPath.html
