Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38695
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <486ABB59.4070602@zend.com>
Date: Tue, 01 Jul 2008 16:18:49 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Ralph Schindler <ralph@smashlabs.com>
CC: internals <internals@lists.php.net>
References: <486AB5F5.50400@smashlabs.com>
In-Reply-To: <486AB5F5.50400@smashlabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Magic method visibility in PHP 5.3+
From: stas@zend.com (Stanislav Malyshev)

Hi!

> In PHP 5.3 snaps, it appears that magic methods __isset, __unset, __get, 
> __set must have a public visibility or the engine will trigger a 
> warning.  Why is this?  It works as expected in 5.x branches.

I think it doesn't actually work as expected - because as far as I can 
see, visibility is ignored on these methods. Consider this code:

class Foo {
         private function __get($name) {
                 return 42;
         }
}

$z = new Foo();
echo $z->bar;

On 5.2, it happily prints 42, even though you should not have access to 
__get from outside the class, if it were true "private". Having 
"private" there actually is somewhat misleading - while it looks like 
internal API and thus can be changed by the class developer at will or 
dropped altogether, it is actually a public API which is exposed to the 
client.

> I am not sure why this should be enforced as it should be up to the 
> developer as to which methods in the API should be exposed for direct 
> invocation.

I don't think magic methods are meant to be directly invoked. That's why 
they are magic ;) In any case, since these methods are invoked in 
"magic" way anyway, regardless of visibility, putting non-public 
visibility on them makes little sense and actually makes people think 
they can not be invoked from outside of the class - while it is not the 
case, they can. Thus, even if there was no warning, I'd recommend never 
putting non-public visibility on them.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com