On Thu, 2004-03-04 at 13:10, Andi Gutmans wrote:
> Hey,
Hi,
> The reason for this behavior is that in PHP 3 and 4, objects were treated
> very much like arrays (this is the main reason for redesigning the object
> model for PHP 5).
> I don't think that the old behavior is correct and an empty should always
> return true (i.e. empty($var) should return true if the variable is NULL
> and false if $var is an object).
to clarify: Maybe I was misusing PHP by doing the following:
class null {
function null() { }
function __call($name, $args) {
throw(new NullPointerException('Method.invokation('.$name.')'));
}
function __set($name, $value) {
throw(new NullPointerException('Property.write('.$name.')'));
}
function __get($name) {
throw(new NullPointerException('Property.read('.$name.')'));
}
}
class registry {
public static $null;
}
registry::$null= new null();
class ClassType {
function forName($name) {
// ... abbreviated ...
return new ClassType($name);
}
function getConstructor() {
if (!$this->hasConstructor()) return registry::$null;
return $this->constructor;
}
}
$i= ClassType::forName($class)->getConstructor()->newInstance();
What I am doing here is fatal error prevention. To come to my point: The
following statement:
if (ClassType::forName($class)->getConstructor()) {
// ...
}
would now always evaluate to (bool)true. In PHP4 (where, of course, the
syntax need be a bit different) the above statement would evaluate to
(bool)false due to the "emptiness" of the null object.
I know this is kind of hacky but was a nice way of being able to have a
way of implementing a "Fatal error: Call to a member function of a
non-object"-safe "NULL" *and* being able to check for it using boolean
operators.
> I don't think we should by default support the PHP 4 behavior because it's
> just not right. What I suggest is to either break BC completely or support
> the old behavior in compatibility mode.
> What option do you prefer?
I saw you already committed a patch for the latter option (return 0 in
compat mode).
I'm not sure whether this affects a lot of users, and as noone has
commented on it, I guess PHP5 will get away with this break:)
I'll just have to find a workaround if you insist the PHP4 behaviour is
broken:)
- Timm
