On Wednesday, December 01, 2010 8:28:19 am presid...@basnetworks.net wrote:
> > Is this consistent with methods? Do those share a namespace, too? (I > > don't actually recall off the top of my head.) > > methods and variables have their own namespaces. This is because they are > called differently: > > // variable $a > print $f->a; > // method a() > print $f->a(); > > But variables and properties would be called the same way (both $f->a;). > Because of this, they need to share the same namespace in order to avoid > ambiguity. This is in fact a feature of properties, because this way an > existing variable can later be replaced with a property, and all calling > code will continue to work (or at least will compile). 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. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
