Ibuildings - Blog - ibuildings.nl

Blog

Ibuildings, blog

Blog

Harrie's blog

ing. Harrie Verveer ing. Harrie Verveer
Software Engineer
 Zend PHP5 Certified Engineer MySQL Certified Engineer
Harrie is a software engineer at our Vlissingen office. Besides working from the Vlissingen office he occasionally does on-site projects for our customers. In his spare time he is into photography and guitar playing.

Monday, 5 May 2008

Accessing object properties by reference

PHP is a loosely typed language. Most of the time this is very useful because you as a programmer don't have to worry about typecasting: it's done for you. However, on some occasions this can cause some unexpected trouble. These issues can be hard to track down because the error usually doesn't show up at the place where you define your variable, but at the place where you want to use them (which can be in a totally different part of your application).

In this blog I want to point out what can happen if you try to access object properties by reference when the object is not initialized. Although this is not caused by typecasting, the encountered problems can be pretty similar on some occasions.
Take a look at the amazing application I just built:

PHP:

<?php

  class myApp
  {
    protected $myVar;
    
    public function runMe()
    {
      $this->printMyVar();
      $a = &$this->myVar->nonExistingArray['a'];
      $this->printMyVar();
      print_r($this->myVar);
    }
    
    protected function printMyVar()
    {
      echo ('The class of myVar is:' . get_class($this->myVar) . "\n");
    }
  }
  
  $myApp = new myApp();
  $myApp->runMe();

?>



Well nothing special really. The printMyVar method tries to display the classname of the myVar member variable. Of course, this won't work as the myVar variable isn't initialized anywhere, so in that case get_class will simply return ''. Then we suddenly start using the variable as an object - basically we try to get a value out of a non-existing array from our non-existing object, by reference (this is probably the code of some really messed up programmer; don't try this at home). What would you expect to happen? You probably expect nothing really. $a would probably stay empty, or some error would occur for using an undefined variable as an object.

Wrong! Instead, trying to access a property in a non-initialized variable by-reference seems to cast the non-initialized variable ($myVar) into an object of the class stdClass! That's right, the output of the script above is:

CODE:
The class of myVar is:stdClass
stdClass Object
(
    [nonExistingArray] => Array
        (
            [a] => 
        )

)


We even created our array with the arraykey 'a' and no value! Amazing, isn't it? Please note that this only happens when you try to get the value by-reference. This of course allows us to fill our array by setting $a, and by that I can imagine this feature can be very powerful as long as you actually intended to use it that way. In fact PHP is saying "Okay so you want access to an undefined array key in an undefined array in an non-existing object? No problem let me create them for you.". On the other hand, in some occasions (especially larger applications than the example above) this can cause some trouble. When you forget to create an object and you try to access it this way you are suddenly talking to an stdClass-object instead of the fooBar-class you actually intended to use. You might not even see an error at that point, but the application could act weird or cause an error in a totally different part of your application (for example when you try to call a method on the object).

So how to prevent this? First of all, don't forget to create your object :-). Besides that people should be careful with using '&' for accessing object properties by-reference. On some occasions this can be useful, but most of the time you can get away with the 'normal' way of getting and setting those values:

CODE:
$a = $this->myVar->nonExistingArray['a'];


Getting the value by-value instead of by-reference won't create an object. Don't worry about memory usage, because PHP uses lazy copy which means the value won't be copied until you actually change its value - so if you just want to know the value and not change it this works fine. And of course when we want to change the value we can use:

CODE:
$this->myVar->nonExistingArray['a'] = 2;


This will simply cause an error when myVar isn't an object, so is a lot safer to use as well.

So to sum things up:
  • When you want to create an object, don't forget to create it
  • Be careful with getting values by-reference and only use it when you really have to
Geplaatst door Harrie Verveer in planetphp op 14:23 | Reacties (8) | Trackbacks (0)
Tags voor deze bijdrage: , ,
Share

Trackbacks
Trackback-URI voor dit artikel

Geen Trackbacks

Reacties
Geeft reacties weer als (Lineair | Samengevoegd)

'This will simply cause an error then myVar isn't an object' confused me for a moment, guess it's a typo for 'when'?

Thanks for the article
#1 Anoniem op 06-05-2008 12:32 (Beantwoorden)
Ah, yes that's a typo. Fixed it now. Thanks for letting me know!
#1.1 Harrie Verveer op 06-05-2008 12:54 (Beantwoorden)
Don't you think that protected member require special cases and treats? There's nothing unusual here IMO, except the fact that you really do not care about protected variable.

BTW, please use English in comment's form ;-)
#2 Piotr Pokora op 08-05-2008 18:10 (Beantwoorden)
Hi Piotr, I'm not 100% sure if I get your question right. In this example there is no difference between protected membervars and public membervars - both will have the same effect. In other words: if you make the membervar (and/or the printMyVar method) public there won't be a difference - output remains the same.

Just to make sure: the 2 last code examples are ment to be in a method in the same class, for example in the runMe method. Now I look at it I see it can cause some confusion because they're just lines of code without any context.

I hope this answered your question, if not please let me know.

On and for the English form, click 'English' on top of the page and let the magic happen ;-)
#2.1 Harrie Verveer op 08-05-2008 20:55 (Beantwoorden)
Yeah, protected or public type won't change much here :-) For me it's quite obvious that PHP must do some variable fallback and instantiate StdClass in this case. My point is that you showed example with protected member, and if I would like to write derived class I would be very unhappy that parent class has no enough type validation for protected members :-)
#3 Piotr Pokora op 13-05-2008 14:05 (Beantwoorden)
Clearly this is unwanted behaviour of the Zend Engine, but not something you would easily encounter, unless you care squat about good practice.

Yet another reason NOT to expose an objects inner structure, and use accessor methods.
#4 John Kleijn (Homepage) op 22-06-2008 21:42 (Beantwoorden)
I just encountered this behavior this afternoon, and was stumped by it until I read your article. Very insightful! And while I'm tempted to forge ahead and leave this crazy code in place, ultimately it is so bizarre that I think other developers would have a hard time finding it if an issue ever arose.

The application in question uses a large, multi-level, hierarchical hash table to keep track of many resources. I'm delegating branches of the table down in the hierarchy, passing them by reference so that changes made are automatically reflected in the main.

Using previous code as a template, I had added a level and unknowingly specified a branch that was not yet available as part of a __construct call, passing it in by reference. PHP went ahead and created the relationship. Later, when the data elements were populated, the relationship worked exactly as expected. I only caught the behavior by watching closely in my IDE, and wondered why I didn't see the attribute being set at instantiation. PHP must have made a StdClass in the background, as you said.

It was easy, but it doesn't feel right. Thanks for the article!
#5 Todd Lewis op 10-11-2011 01:03 (Beantwoorden)
Amazing that my blog post apparently is still useful even three years after writing it! Yes, it's a tricky problem and I'm glad my article helped you to track it down. Did you change anything in your methodology to prevent the problem from occurring again? (This might be a great advice for other developers!)

Thank you for your reply!
#5.1 Harrie (Homepage) op 16-11-2011 11:14 (Beantwoorden)

Reactie toevoegen

BBCode opmaak toegestaan
Met sterretjes wordt tekst *vet* gemaakt. Met underscores kan een _woord_ onderstreept worden.
Standaard emoticons zoals :-) en ;-) worden geconverteerd naar plaatjes.
Email adressen worden niet getoond en zijn alleen zichtbaar voor de blogger.

Om het posten door robots tegen te gaan, gelieve de letters die je in het plaatje ziet over te typen. Je commentaar wordt enkel gepost wanneer de letters overeen komen. Je browser dient cookies te ondersteunen (standaard staat dit aan), of je commentaar kan niet geverifieerd worden.
CAPTCHA
 
 

Benelux (wijzig / change)