On Tue, Apr 30, 2013 at 7:34 PM, Adam Harvey <ahar...@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.
