>> > The "original purpose" being, specifically, "smarter class members", >> > correct? (The internal syntax to define them we can bikeshed later; >> > determining the external syntax and semantics has to come first.) >> >> Well when saying "original purpose" I was referring to exactly this: >> >> "The basic Idea of a property, is making a getFoo() / setFoo($value) >> pair >> of methods look and act like a variable from the outside, and have an >> easily identifiable and simple to use syntax on the inside." >> >> But I suppose you could just boil that down to "smarter class members" >> ;) >> >> - Dennis > > Well, there's a very subtle difference in those two statements. :-) > That's > what I'm saying. If the goal of properties is "to allow a developer to > bind > arbitrarily complex behavior to what would otherwise look like a class > member", that's fine and useful and I support it. But there are, > technically, > multiple very different ways that could be implemented. An inline set of > get/set methods is one way. Creating a property as a reuable > free-standing > entity alongside traits and classes would also accomplish that goal. > Creating > a free-standing super-variable dojobby would work, too. Technically > __get/__set also accomplish that goal now (although in a sub-optimal way). > > I'm trying to draw a very clear line between the syntactic interface and > goal, > and the implementation. That's important for us to keep the design clean. > > And I think I'm done harping on this point now, I hope... :-)
Ah, I see. In that case, to use your words, I would say "An inline set of get/set methods" was my intention. This also leaves open the door to allow properties to be added to a trait definition which will also support re-usability. The supervariable thing I am not too keen on though. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
