On Sunday, December 05, 2010 11:07:49 am presid...@basnetworks.net wrote: > > 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... :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
