Re: protected __call() question

maybe its possible for the parser to ignore public/private/protected declarations on __call() (& also __set(), __get()) methods, given PHP forgiving nature/image (at least that is my impression). at the very least spare php-general a ton of emails by mentioning it prominently in the documentation. -- conceptually speaking I'd don't think my PHP code should be concerned with 'the engine' in this regard, an undefined method was called this is handled by __call(), in the code the stack would go from CallMe::setup() to CallMe::__call() assuming PHP5 offers the such functionality for undefined methods, which is does. to me this seems, not broken, but incorrect in terms of behaviour. having said that I like PHP5 enough to just remove the 'protected' declaration and carry happily on as if nothing had happened! (my inner,perfectionist self will secretly keep hoping this is fixed so that I can make the __call() method on the particular object in question protected again, private even!) for what its worth +1 on making this a feature request. and keep up the good work! Marcus Boerger wrote:

Hello Ferdinand, that seems to be the current argument - but we have changed otehr places like that already so we should make this feature request or even bug. marcus

...

Ah, now I understand your point. But __call() is called by the engine, not by setup(), so it is the outside world....

Class CallMe {

    public function setup()
    {
        $this->fakeMethod();
    }

    protected function __call($method, $params)
    {
        echo 'you called CallMe::'.$method."\n";
    }

}

..