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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
