Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42537
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.16 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:to:subject:cc:in-reply-to
         :mime-version:content-type:content-transfer-encoding
         :content-disposition:references;
        b=M3GZM2jj/JgpKOonJKbQm7wdTU6/nzZJNQrwrrKiAqAFB1r+713AkCyUPpxabEL5nI
         JeTe7ucqtUKPq0s/WuJ21smplFIA26bD4tguG52KFYZTBcL7+2Cc+Sd6+hxOHha/twUa
         +EpXO+vR7CJgPVKW4OCPDYK/xICc7EGyMp0Ls=
Message-ID: <5a8807d10901080900w5d794c54gc67df2198e2237f7@mail.gmail.com>
Date: Thu, 8 Jan 2009 17:00:06 +0000
Reply-To: robin@soal.org
To: "PHP internals" <internals@lists.php.net>
Cc: "Andrei Zmievski" <andrei@gravitonic.com>, "David Coallier" <davidc@php.net>
In-Reply-To: <b5f7bf6c0901061440t7ac9382fj1141a6fbdeb22f0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4963D8AD.5090502@gravitonic.com>
	 <b5f7bf6c0901061440t7ac9382fj1141a6fbdeb22f0@mail.gmail.com>
Subject: Re: [PHP-DEV] Private member/method access inconsistency
From: rewbs.soal@gmail.com ("Robin Fernandes")

2009/1/6 David Coallier <davidc@php.net>:
>> call to __call() on private method invocation. The former approach presents
>> more of a BC
>> problem IMHO, so I am advocating the latter. I've attached a simple patch
>> for consideration.
>>
>
> I'd say go ahead, this sounds like common sense to be consistent in
> both methods and members.
>

Cool, looks like this has gone in already. A couple of comments:
1. I think the change has not been made for callbacks (so callbacks
now behave differently from normal method invocations).
2. Perhaps on 5_3 and HEAD, the equivalent change should be made for
__callStatic()?

Addressing those two points would make things even more consistent.
I'm adding some testcases to illustrate.


--TEST--
Trigger __call() in lieu of non visible methods when called via a callback.
--FILE--
<?php
class C {
	protected function prot() { }
	private function priv() { }
	public function __call($name, $args)    {
        echo "In __call() for method $name()\n";
    }
}

$c = new C;
call_user_func(array($c, 'none'));
call_user_func(array($c, 'prot'));
call_user_func(array($c, 'priv'));
?>
--EXPECTF--
In __call() for method none()
In __call() for method prot()
In __call() for method priv()



--TEST--
Trigger __callStatic() in lieu of non visible methods when called
directly or via a callback.
--FILE--
<?php
class C {
	protected static function prot() { }
	private static function priv() { }
	public static function __callStatic($name, $args)    {
        echo "In __callStatic() for method $name()\n";
    }
}

echo "Using direct method invocation:\n";
C::none();
C::prot();
C::priv();

echo "\nUsing callbacks:\n";
call_user_func(array('C', 'none'));
call_user_func(array('C', 'prot'));
call_user_func(array('C', 'priv'));
?>
--EXPECTF--
Using direct method invocation:
In __callStatic() for method none()
In __callStatic() for method prot()
In __callStatic() for method priv()

Using callbacks:
In __callStatic() for method none()
In __callStatic() for method prot()
In __callStatic() for method priv()