DEV Community

Laravel Greatest Trick Revealed: Magic Methods

Steven Yung on April 15, 2019

Photo by Mervyn Chan on Unsplash Laravel has leverage PHP to a whole new level, providing awesome Developer Experience (DX) to craft your next pr...

Read full post

Michael J Brown • Apr 15 '19

As somebody that is just learning the basics of php, OOP and playing with laravel passively, this article was incredibly helpful. Thank you!

Steven Yung • Apr 15 '19

If it was clear for you then my mission is done !

Thank you for the kind words and keep on learning, Laravel is incredible and extremely rewarding ! 💪

Yaron Strauch • Jun 9 '20 • Edited

The magic method __set however has a trap that I fell into and needed many hours to debug.

Say you have your nice object, say Airplane, with a static function to initialise an airplane from some other data.

class Airplane extends \Illuminate\Database\Eloquent\Model {
   private $name;

   public static function fromSomething($foo) {
       $airplane = new Airplane();
       // do something awesome with $foo to derive the name
       $airplane->name = "Airbus";
       $airplane->save();
       return $airplane;
    }
}

And obviously from somewhere else you call $airplane = Airplane.fromSomething($foo), and that part works as expected. But then you check your database (or fetch the model again through eloquent) and... It's empty! Well except for the created/modified timestamps. The rest is just empty.
The caveat: Php docs specify: __set() is run when writing data to inaccessible (protected or private) or non-existing properties. So it's not called because we have write access to the method! This means that all the cool eloquent magic to update your attributes is knocked out.
Solutions? Well just don't define the variables in your class. Which goes against all OOP tutorials out there (including this one) and any programming intuition. Or don't use static initialisers, which is a well-known design pattern. Or add it manually to attributes, therefore implementing framework functionality (variant: call __set yourself). Or use inheritance and use protected (but are they gonna be protected? Don't know either). Maybe there are more solutions? I will stick to the first one and stop defining the fields in my class.

Krisztian Papp • Apr 16 '19

Just a note that magic methods are several times slower than accessing a properly defined variable. It might sound cool and stuff for RAD, but no magic comes without a price.