Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67236
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.220.169 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADajX4A_mhJoMoDtG=SH9UPqcXUxN0i3EfKkSWn27fJDUGWP_g@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>
Date: Tue, 30 Apr 2013 19:55:55 -0400
Message-ID: <CADqTB_hidduzyNhpbmqrS1KZTrG7MUneKOLn1eqUyb=MmaBXMw@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf307c9b6af5dc7d04db9cbd93
Subject: Re: [PHP-DEV] property de-referencing
From: rasmus@mindplay.dk (Rasmus Schultz)

--20cf307c9b6af5dc7d04db9cbd93
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 30, 2013 at 7:34 PM, Adam Harvey <aharvey@php.net> wrote:

> I would caution against generalising use cases. Personally, ::class is
> something I can use multiple times a day. This I'm not so sure about.
>
> Your use case is not my use case, and vice versa. :)
>

What is your use-case then? DI perhaps?


> Why does this have to be a language feature?
>

I already covered that.


> It obviously already works in userland, as your own Symfony 2 examples
> show.
>

As explained, this is not intended to solve a problem that can't currently
by solved by other means, but to strengthen the static aspects of the
language.


> 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.

Yes, you can already create property-references at run-time - for that
matter, you could already use new ReflectionProperty($obj, 'prop') to do
what you demonstrated above.

But the property-name, in the source-code, is a string - it has no literal
relationship to YourClass::$prop where as ^$obj->prop does.

No mainstream framework provides a PropertyReference class, because it
wouldn't accomplish anything - the property-name is still a string, it's
still unchecked, and still can't (reliably) be used in static analysis.

--20cf307c9b6af5dc7d04db9cbd93--