> See, here's the fundamental problem we're running into. There's three > different definitions of what a property is that we keep bouncing between, > each of which will dictate both syntax and semantics: > > 1) Properties are a smart masking layer over class members, like a smarter > __get/__set, designed to make it possible to swap out in place of class > members at will. In this case, both the syntax and semantics of > properties > should mirror class members as close as possible. > > 2) Properties are a short-hand for getFoo()/setFoo() methods (which in the > general sense should *not* be understood to always map to class members, > as > discussed), designed to make typing $o->getFoo() and $o->setFoo() > shorter/easier. In this case the syntax and semantics should make that > clear > and not confuse the user with class-member-like syntax. > > 3) Properties are a completely different animal, neither methods nor class > members but a totally different concept. In this case the syntax should > not > be confusing with either methods or class members, and the semantics > should > probably then be taken from the most common/popular existing > implementation > feasible. > > We cannot mix #1 and #2 and expect to get something usable out the other > end, > nor can we defend doing so on the grounds of #3. The discussion of the > proposal is doing exactly that, however, which I think is a fatal flaw. > > Personally, if we follow approach #1 (make them look and smell as much > like > class members as possible) then I'm all for it in concept. It might even > simplify many of the regular arguments I have about public "properties" > and > good architecture. :-) But only if we can cleanly stick to one definition > of > purpose, syntax, and semantics. > > Treating properties as a method implementation that can work like class > members if you look at them from the right angle even though they're not > class > members and don't really work like them is a sure-fire way to confuse the > hell > out of people. > > PHP is complicated enough without introducing wave/particle duality.
I agree Larry, the discussion is all over the place, but I think it is good because a lot of great ideas are coming up, and most of the bad ideas are getting flushed out. I think everyone needs to work through all of the possibilities before we come to a consensus on what is best. 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. The reason I originally focused so much around methods, is because properties literally are a pair of methods in C# (thats what they are compiled into). But PHP is another beast, and the challenges are different. As long as the original purpose of properties is not loss, whatever way we figure out is best to implement them is fine with me. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
