Jeff Moore wrote:
> Would this patch (or another
> like it) allow for the elimination of the current recursion guard for
> __get, etc?
The code below echoes "it works" on PHP_5_1 and HEAD but raises a notice on
the other branches.
there;
case 'there':
return 'it wor
Bart de Boer wrote:
Maybe introduce an optional second argument "decodetype" to
json_decode() where you could pass on a constant like JSON_ARRAY or
JSON_OBJECT?
For example:
$assoc_array = json_decode($json_string, JSON_ARRAY);
$object = json_decode($json_string, JSON_OBJECT);
I'm not
Andrew Yochum wrote:
Consider a situation where a proxy/mediator/broker class implementing
__call proxyies method calls to other classes (possibly of 3rd party
origins), which themselves may or may not implement __call. You'd like
the broker itself to have a consistent behavior for the sake of i
Marcus Boerger wrote:
If you need more it is up to you to provide
the infrastructure. Remember we will not in anyway allow __call to handle
inheritance.
Hi Marcus,
If one is determined enough, at least visibility can be faked by exception
trace introspection. Below demonstrates protected, re
Hi Andrew,
Andrew Yochum wrote:
Consider that one may only
want __call to respond to a computable set of overloaded method names.
Usually, this is done by something like this:
throw new Exception('Call to undefined method ' . __CLASS__ .
'::' . $method . '()');
}
p://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Mike Naberezny
Senior PHP Developer
Zend Technologies, The PHP Company
19200 Stevens Creek Blvd, Suite 100
Cupertino, CA 95014
Tel: 408-342-8891
Fax: 408-253-8801
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
