[9dev]

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->bar. There really have been both more invasive and more Java-style features in the past than this one.

[shikck200]

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 (like getFoo()) it was annoying, but still obvious, now its just magic and library authors will 100% start to abuse this feature allover.

[9dev]

> I now cant tell if im accessing a property or a getter.

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)
          };
      }
  }

The difference to a proper getter is that you never knew Foo supported the virtual properties "bar" and "baz"; the only chance you'd have was if I added doc comments, or a note in the documentation; otherwise, good luck finding it in the source code. Compare to:

  class Foo
  {
      public string $bar
      {
          get => $this->doSomeHeaveIoOp();
      }

      public string $baz
      {
          get => query_db();
      }
  }

This is definitely better. It is discoverable by both you and your IDE; it allows proper documentation; it is not magic, but code; it won't go out of sync with the __call handler; it allows static analysis and typing.

> 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.

[shikck200]

Its obvious that this has been possible before. It always was bad practice to do so, no matter of the language. I for see people starting returning `$this` and having these really complex chains of getters. Its going to turn into even more spaghetti, because now there is two syntaxes for basically doing the same thing. It seems simplicity is just something everyone wants to abandon.

[Timon3]

> It seems simplicity is just something everyone wants to abandon.

I think this very much depends on your perspective. "Simplicity" isn't a single dimension, you'll always face trade-offs at some point.

While the language did get slightly more complicated with the introduction of property hooks, they also simplify a lot of real-world code. Instead of handling all getter/setter logic inside two big functions, there's now a direct relation between each property and its getter/setter logic. There's a lot of value in that!

Of course you can say that's not good practice and therefore shouldn't be made simpler, but then you're still offloading complexity onto the individual program and developer. They are using these features in production code, and keeping the language simpler means that every class using getters/setters has its own custom logic. That's not simple at all!

To give a real-world example, Typescript supports many things that probably wouldn't be necessary if the language were designed from the ground up. But it's meant to add type safety to Javascript, so it has to support adding types to patterns that aren't best practice. But this also simplifies adding types to the existing ecosystem by a large margin, which is arguably the reason it has become the de-facto best practice for writing frontend apps.