Overloaded properties (__get) [ Saturday, 19th of August, 2006 - 18:34 - Skien, Norway ]

While checking whether the eZ components would run with the latest PHP 5.2 release candidate we noticed that there are some things that are not backwards compatible with PHP 5.1.

The first issue is an extra notice in some cases. In our (ezcMailTools) class we implement a method that allows you to "reply" to a parsed e-mail message. In this method we have the folowing code:

static function replyToMail( ezcMail $mail ) { // ... foreach ( $mail->to as $address ) { // ... } // ... }

As you can see we loop over one of the seemingly public variables of the $mail class. However, the ezcMail class does not have this as a public member variable, but instead uses overload as you can see in this code snippet:

public function __get( $name ) { switch ( $name ) { case 'to': return $this->properties[$name]; } }

This all works 'fine' with PHP 5.1, however with PHP 5.2 the following notice was generated for this code:

Notice: Indirect modification of overloaded property ezcMail::$to has no effect in ../Mail/src/tools.php on line 364

The reason for this is that __get() only returns variables in read mode, while foreach() wants a variable in read/write mode as it tries to modify the internal array pointer. As it can't do this PHP 5.2 will now throw a warning on this.

There is a workaround however in the form of casting it to an array. After our changes the code now looks like:

public function __get( $name ) { switch ( $name ) { case 'to': return (array) $this->properties[$name]; } }

The second issue is related to this. In this case we did not see an extra notice but instead a fatal error:

Fatal error: Cannot assign by reference to overloaded object in .../trunk/Url/src/url.php on line 242

The code around this line is:

if ( array_key_exists( $index, $this->path ) ) { $this->path[$name] =& $this->path[$index]; }

In this case $this->path is also an overloaded property returning an array. Because __get() returns a read-only variable assigning a reference can not work as that requires a variable to be in read/write mode. Most likely the code didn't work properly in PHP 5.1 either but luckily this is still in an unreleased component. However, I am not aware of a work-around here.

Davey Shafik - Saturday, 19th of August, 2006; 19:31:19
Why doesn't PHP just return in read/write mode? :)

- Davey

SantosJ - Saturday, 19th of August, 2006; 20:45:15
How about:

foreach($mail->getAddresses() as $whatever) { ... }

Daniel - Saturday, 19th of August, 2006; 22:58:16
Using __get() or other overloading functions is not good code style. In this case you dynamically change your interfaces to a class component which makes the good harder to understand and to maintenance. Use getter-methods for object properties and real properties instead and maybe an interface to hide a specific implementation. Overloading properties of a class has only very few cases where it could make sense to use it. This is not one of them. It is nice, that the PHP developers take care of the availbility of object orientation, but they break the consistent structure it aims with such silly methods of __get() or __sleep(). Other, pure object oriented language don't have these features either and although they use patterns to achieve a good and clean solution. Please make well object oriented style, or PHP will be ill-reputed as a kiddie and unprofessional language forever.

SantosJ - Sunday, 20th of August, 2006; 04:34:07
PHP doesn't return __get() magic properties in read/write mode, because it thinks that it can't write to the property. It could probably be avoided if another variable was used instead.

$to = $mail->to;

or

$to = (array) $mail->to;

foreach($to as $address) { }

But I haven't tested this. I'm going to have to change some of my own code also.

However to PHP, any property from __get() may not have the same property in __set() and PHP may not be intelligent to know whether or not both exists.

It is better this way and very annoying.

FlorentG - Monday, 21st of August, 2006; 10:35:01
Is it the same problem as in http://bugs.php.net/b... ? Because they said it was fixed...

Derick - Monday, 21st of August, 2006; 11:10:59
@FlorentG: The fatal error was changed to a notice in order to "fix" it.

Michaël Guitton - Tuesday, 22nd of August, 2006; 14:51:26
Just wonder why you don't implement a __set() method as a workaround for the second issue you met.

Sergey - Friday, 8th of December, 2006; 18:29:59
you can avoid this Notice if use @ in foreach statement:

foreach (@$this->videos as $video) {
}

Jeroen - Saturday, 30th of December, 2006; 02:36:38
Nice docs, what did you use for those?

Derick - Monday, 1st of January, 2007; 15:37:55
We're using php documentor with our own templates and a small patch to facilitate property documentation.