I suggested something similar earlier: http://marc.info/?t=136327849600002&r=1&w=2
However, I withdrew that idea, because I came to the realization that, for practical applications, you usually need the object-context coupled with the member-reference to do anything really useful. A form-input abstraction, for example, needs the object-context to reflect on the class, the property-reference to reflect on annotations (maybe) and of course the property-value, plus the ability to apply a posted value back onto to the object-property. The proposed feature facilitates all of that. At the risk of starting a separate discussion, the recently added ClassName::class constant provides a way to statically reference a class, which frankly has very few practical applications in comparison - the need to reference properties is usually much more prevalent and repetitive than the need to reference a class; assuming your classes have more than one property each, heh. The feature as such is also somewhat crippled, since what comes out of it is a string and not a class-reference. It solves the problems of static class-references of course, so that's positive - but where's the much more critical property-reference counterpart? Because this feature overloads class-constant syntax, there is no obvious counterpart for properties. It seems pretty short-sighted. If referencing a class statically is necessary and important enough to make it into the language, why are property-references considered less important or valuable? Try to think of these features in terms of completing or complementing the fairly limited static side of an otherwise mostly dynamic language, rather than as features intended to solve a specific programming problem as such. I think there is still a pretty strong case for static property-references, but since any new language-feature is generally a pretty hard sell around here, I'm letting this one go for now. The immediate impact and benefits of static object-property references ought to be a much easier sell - it has pretty broad applications, and can probably replace a lot of simple inline function-closures, and eliminate a lot of double-arguments (object and property-name) from many popular/mainstream libraries. If you disagree, please explain by example. I've already put a lot of time into thinking about this and explaining it pretty carefully. If you're opposed for more than personal reasons, surely you can offer more than a flippant one-line backlash? :-) On Tue, Apr 30, 2013 at 6:20 PM, Lazare Inepologlou <linep...@gmail.com>wrote: > > > 2013/4/30 Rasmus Lerdorf <ras...@lerdorf.com> > >> On 04/30/2013 01:58 PM, Stas Malyshev wrote: >> > Hi! >> > >> >> I'm proposing we need a way to statically reference an object property >> - >> >> the object property itself, not it's value: >> > >> > You probably have use case for that, and it should be pretty easy to >> > write a class that does that, but why it should be in the language? It >> > certainly doesn't look like something sizeable portion of PHP devs would >> > do frequently. >> >> It is certainly not worth overloading the XOR operator for. >> >> -Rasmus >> >> > In C#, they had the intention to introduce the operator infoof(...) to get > the reflection, not only of properties, but of virtually everything in the > language. They abandoned the idea because it is really hard to do that for > overloaded functions and they did not want to do all that work for a half > baked feature: > > > http://blogs.msdn.com/b/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspx > > However, PHP does not have overloaded functions, which makes things > significantly easier, so maybe it is worth examining the idea. > > > Lazare INEPOLOGLOU > Ingénieur Logiciel > >
