Re: Property Overloading RFC

I don't think __call/__get/__set should be resolving visibility. Maybe that's the difference. It's main purpose is to allow exposing a dynamic public interface. I understand exactly where he was going with this, and I just don't think PHP is the right place to do it. Andi At 02:55 AM 8/26/2005, Derick Rethans wrote:

On Thu, 25 Aug 2005, Andi Gutmans wrote: At 06:00 AM 8/25/2005, Edin Kadribasic wrote:

Derick Rethans wrote:

And how can you possibly argue that this more complex than

all the other

OO crap that people are suggesting here....

I belive that we should do our best to filter out this storm of OO feature requests. People want to make PHP look like some other OO languages for no good reason other that they're familiar with it or that their CS teacher thought they were cool.

I completely agree. This very much bloats the language syntax and would be mainly there for the sake of OO fanatics. Guys, seriously, this kind of stuff and a lot of the other OO proposals I've heard here lately are going to lead to PHP going down the drain. Derick, the fact that you say it's not worse than "other OO crap that people are suggesting here...." just means that it's also good to leave the other crap out of PHP. I'm just arguing that the current way that setters and getters are implemented is broken. Instead of keeping a broken behavior I would like to see it fixed. I don't see why the __get/__set/__isset/__unset methods themselves can't check if the property exists and throw an exception if it doesn't. It has more to do with problems with encapsulation and visibility. Frederik made a nice summary of that, he will reply here: Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org