Overloaded properties (__get)

Saturday, August 19th 2006, 18:34 CEST

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.

Shortlink

This article has a short URL available: https://drck.me/opg-4w0

Comments

Davey Shafik

Saturday, August 19th 2006, 17:31 UTC

Why doesn't PHP just return in read/write mode? :)

Davey

SantosJ

Saturday, August 19th 2006, 18:45 UTC

How about:

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

Daniel

Saturday, August 19th 2006, 20:58 UTC

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, August 20th 2006, 02:34 UTC

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;

$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, August 21st 2006, 08:35 UTC

Is it the same problem as in http://bugs.php.net/bug.php?id=38146 ? Because they said it was fixed...

Derick

Monday, August 21st 2006, 09:10 UTC

@FlorentG: The fatal error was changed to a notice in order to "fix" it.

Michaël Guitton

Tuesday, August 22nd 2006, 12:51 UTC

Just wonder why you don't implement a __set() method as a workaround for the second issue you met.

Jeroen

Saturday, December 30th 2006, 01:36 UTC

Nice docs, what did you use for those?

Derick

Monday, January 1st 2007, 14:37 UTC

We're using php documentor with our own templates and a small patch to facilitate property documentation.

tom

Thursday, May 26th 2011, 22:09 UTC

function &__get($name) {...}

This returns a reference instead of a copy, but still has a few quirks.

The only time I have had an issue with the above is when I'm doing a $this->var1 =& $this->var2. (The double reference screws everything up.)

Add Comment

Name:
Email:	Will not be posted. Please leave empty instead of filling in garbage though!
Comment:	Please follow the reStructured Text format. Do not use the comment form to report issues in software, use the relevant issue tracker. I will not answer them here.
	All comments are moderated