Should You Use PHP’s Magic Methods or Not?

As mailto:matthew@matthewsetter.com[a freelance PHP developer], I’m always looking to improve the quality of the applications I produce. So, over the last 6 - 12 months, I’ve been learning as much as possible about link:/tags/testing/[testing]. During this time, I’ve found the way I code is dramatically changing – and improving!

Some constructs, both large and small, which I’ve used habitually for many years, have been falling by the wayside, as I find out they’re either extremely difficult or impossible to test. For example, In a recent development session, I attempted to test some of my https://docs.laminas.dev/laminas-db/[laminas-db] based classes, which use https://www.php.net/manual/en/language.oop5.magic.php[PHP's magic methods] for dynamically building where clauses.

Here’s an example:

[source,php]

$select ->where ->lessThanOrEqualTo( “dateOfBirth”, new \Laminas\Db\Sql\Expression( sprintf( “STR_TO_DATE(’%s’,’%%d-%%m-%%Y’)”, $searchCriteria->getValue(“endDate”) ) ) );

The code calls lessThanOrEqualTo() on the dynamic property, where, to find records which have a dateOfBirth field value no later than the formatted date supplied. The where property is provided by an implementation of https://www.php.net/manual/en/language.oop5.overloading.php#object.get[the __get magic method] in \Laminas\Db\Select, which you can see below:

[source,php]

public function __get($name) { switch (strtolower($name)) { case ‘where’: return $this->where; case ‘having’: return $this->having; default: throw new Exception\InvalidArgumentException( ‘Not a valid magic property for this object’ ); } }

The method returns $this->where which is a https://docs.laminas.dev/laminas-db/sql/#where-and-having[\Laminas\Db\Sql\Where] object. This, in turn, extends https://github.com/laminas/laminas-db/blob/2.16.x/src/Sql/Predicate/Predicate.php[\Laminas\Db\Sql\Predicate\Predicate]. The level of indirection aside, it’s not that complex and, personally, I like the simplicity and flexibility of it.

But Is It Testable?

I can’t speak for what it’s like using https://phpunit.readthedocs.io/en/9.5/test-doubles.html?highlight=mock#mock-objects[PHPUnit's mock objects,] as I always use http://docs.mockery.io/en/latest/[Mockery] instead. But after attempting to do so in Mockery, I hit a stumbling block when trying to test the chained call. Not being able to resolve it, I turned to #zftalk on IRC (now https://laminas.slack.com) and after some discussion there, I https://github.com/padraic/mockery/blob/master/README.markdown#mocking-public-properties[revisited the manual] to find the following:

PHP magic methods which are prefixed with a double underscore, e.g. _set(), pose a particular problem in mocking and unit testing in general. It is strongly recommended that unit tests and mock objects do not directly refer to magic methods. Instead, refer only to the virtual methods and properties these magic methods simulate. Following this piece of advice will ensure you are testing the real API of classes and also ensures there is no conflict should Mockery override these magic methods, which it will inevitably do in order to support its role in intercepting method calls and properties.

This lead me to start re-evaluating my attitude to PHP’s magic methods. Whereas previously I’ve loved using them for their simplicity and compactness, now I’m not so sure if the convenience is worth it.

As the manual suggests, “mock on the properties which the magic method refers to”. Fine, not a deal-breaker. But perhaps it’s time to stop using them. Maybe it’s time to write more getters and setters instead, in the name of fully testable code. Maybe, while handy, they’re not worth using.

During research on the topic, I came across this http://stackoverflow.com/questions/6184337/best-practice-php-magic-methods-set-and-get[Stack Overflow article], which in the comments, people make good arguments for and against.

Here are 3 examples:

Also, magic methods aren’t going to work with interfaces and abstract classes/methods. And what about visibility? It’s a leak to have a private or protected property modifiable by a magic __set method. Add these to your examples and I agree that there are many good arguments against using magic methods for getter/settersand no real arguments in their favor. For quick one-offs, maybe use them for something, but they’re not a best practice for reusable code/libraries/APIs.

You should use stdClass if you want magic members, if you write a class - define what it contains.

Yes, this is exactly that :p. But another thing I forgot to mention is that: having getters for properties is more coherent with “real” methods where getXXX is not only returning a private property but doing real logic. You have the same naming. For example you have $user->getName() (returns property) and $user->getToken()

Here’s a summary http://blog.webspecies.co.uk/2011-05-23/the-new-era-of-php-frameworks.html[from the article] which triggered the post:

First of all, back then it was very popular to use PHP’s magic functions (__get, __call etc.). There is nothing wrong with them from a first look, but they are actually really dangerous. They make APIs unclear, auto-completion impossible and most importantly they are slow. The use case for them was to hack PHP to do things which it didn’t want to. And it worked. But made bad things happen.

Interestingly, in the interests of speed, https://developers.google.com/speed/articles/optimizing-php?hl=de&csw=1[Google suggests] to:

Avoid writing naive setters and getters.

Instead, they suggest declaring class variables with public visibility. Though, from my interpretation of the post, that’s only for the case of simple get and set, not where extra logic is required.

What’s your opinion?

I’ve decided to reevaluate using them for the time being and be more judicious in the use of them. What about you? Where do you stand? Do you avoid them, or can you not live without them? Share your thoughts in the comments.