Earlier quoted context omitted.
Look at it this way: getters/setters are the only conceivable way Laravel could ever get something like static analysability, and I wouldn’t call that framework particularly Javaian. What they do is make a whole sleuth of magic code actually discoverable and understandable, but you’ll never have to use them if you don’t want to. And even if a library under the hood implements a getter, all you’ll see of that is $foo-…
I really dont want to access a property and have it do any sort of magic behind the scenes. This is just bad. Now a property lookup could do some IO, or even throw an exception. PHP should not aim to please the framework of the month, but it in fact seems like Laravel lobbied this into PHP core. > but you’ll never have to use them But i do. I now cant tell if im accessing a property or a getter. With custom functions…
But you never could have been sure for the last 20-ish years either? What if my library you're using (and you can be certain at least one of them does) includes a class like this:
class Foo
{
public function __get($prop) {
return match ($prop) {
'bar' => $this->doSomeHeaveIoOp(),
'baz' => query_db()
default => throw new RuntimeError('Invalid property ' . $prop)
};
}
}
class Foo
{
public string $bar
{
get => $this->doSomeHeaveIoOp();
}
public string $baz
{
get => query_db();
}
}
> I really dont want to access a property and have it do any sort of magic behind the scenes. This is just bad. Now a property lookup could do some IO, or even throw an exception. PHP should not aim to please the framework of the month, but it in fact seems like Laravel lobbied this into PHP core.
Without any kind of property overloading, you're missing out on a lot of API simplification that other languages have long taken for granted. You may not like it, by stuff like pandas in Python wouldn't be possible at all without heavy overloading, and I prefer a world with pandas over one without it. Ergonomics are important; not writing tons of useless boilerplate code is, too.