Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67269
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_hidduzyNhpbmqrS1KZTrG7MUneKOLn1eqUyb=MmaBXMw@mail.gmail.com>
References: <CADqTB_gkE-2mmnE8AKWCx3rcHf8DVsgxVPO00usErnaoKjAv7g@mail.gmail.com>
 <6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net> <CADqTB_iGghhwuKb7StpjY7xogNM76_47rxL3O7G+T0zOK2Lf3g@mail.gmail.com>
 <CALJZF3hQC09_b=yzOF5F6V1ifC5wG1H4RmkTDg02awm0cC-tWA@mail.gmail.com>
 <CADqTB_gxnPt-PzpaBiTmX5iW81VyssvtZW5Ugto2vOw1NsZGZg@mail.gmail.com>
 <CAH-PCH6oHkTweqYsY3UqeaP9Jdqkrmj1DBhxueUv5uU-U7YrPg@mail.gmail.com>
 <CADqTB_gTVm1TMcg5iaUZ-WTZChdpj7s+-vLaa7BK54FA71T-Sg@mail.gmail.com>
 <51803086.6020002@sugarcrm.com> <518030FD.5030504@lerdorf.com>
 <CAMyk_AY5UCVXMmFALiXZA-JsV=gG2kZPTuxdm7Twugz+fbnY_Q@mail.gmail.com>
 <CADqTB_iDzWw4y0iVz2=MGdCPFPeisE933YKMz2Sm9pmMexfmKw@mail.gmail.com>
 <CADajX4A_mhJoMoDtG=SH9UPqcXUxN0i3EfKkSWn27fJDUGWP_g@mail.gmail.com> <CADqTB_hidduzyNhpbmqrS1KZTrG7MUneKOLn1eqUyb=MmaBXMw@mail.gmail.com>
Date: Thu, 2 May 2013 15:06:55 +0200
Message-ID: <CAHjTTqOwo2RCpT6D=3BAuwZdKv-8rKe6+LVbBFpDq+YETk-R6A@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: Adam Harvey <aharvey@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442881a7c0db104dbbbeaf6
Subject: Re: [PHP-DEV] property de-referencing
From: bschussek@gmail.com (Bernhard Schussek)

--f46d0442881a7c0db104dbbbeaf6
Content-Type: text/plain; charset=UTF-8

2013/5/1 Rasmus Schultz <rasmus@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

--f46d0442881a7c0db104dbbbeaf6--