I am also in favour of the change. I would argue though that because it's been in C# for so long, then yes it reduces inconsistencies across programmers/codebases, but introducing it to a language as mature as PHP is now though, might not have the same outcome.

It’s interesting to consider the “magic” criticism in the context of languages like Zig, where devs actively want no hidden control flow. And Properties beyond simple { get; set; } are definitely hidden control flow.

But as you said — it’s been there in C# for a while and imho it’s a good abstraction over getters and setters. Even 2005-era IDEs could manage it fine, making it easy to access the property’s get/set code, so that it wasn’t really magical.

Maybe it’s a culture thing — most C# devs use IDEs. Not sure what PHP devs use, but I suspect tools like PhpStorm will make this easy to work with somehow. Devs using no-LSP editors will likely have a different view.

Properties have been in C# since the very first version. And those, in turn, were largely inspired by Delphi, with the honorable mention of Visual Basic.

My experience is that 99% of the work related to geters and seters is handled by the IDE

Every step on the path to bloat is justified.

  "All these getters and setters manually coded make it feel like Java."

https://projectlombok.org/

While these are certainly a better option automatically generated default getters and setters have been pretty do-able through magic methods for a while now - and with the more robust reflection we now have access to they can be implemented in a safe manner. I'm still pretty happy to hear we're getting it as a baked in feature.

Seriously? Since 5.3 PHP has worshiped at the alter of Java OOP to the extent that writing PHP code is now an exercise in pseudo-Java.

Thanks for correcting me, and sorry for the error. I should have checked before writing.

I'm not a fan of that kind of magic in my languages but such a thing was already easily doable in PHP. You could just have a base class that implements __get and __set so that $this->foo automatically calls $this->getFoo().

Entities, shrentities - it's all just data.

aren't you just managing them in a new syntax now?

stockholm syndrome is real

which getters/setters?

PHP has had the ability to dynamically handle properties for decades so this doesn't hurt readability -- in fact, it makes it better.

I wrote php exclusively only for about two years early in my career but have had to come back to it periodically every once in a while. I find it one of the most difficult languages to be a visitor in. The way variable, array, and class semantics mix can make it hard to decipher the exact behavior of a chunk of code. Especially if you have a mix of "old" procedural and modern OO php, which the projects I work on do.

I'm not bringing this up as a particular criticism of the language, I think it's fine. It is also an experience I have with lisp, where it is fun and easy to write but hard to read when coming back to it after a while away. I just don't think php is a simple language, on several levels. The semantics that I mentioned, combined with the mixing of paradigms, and the large and inconsistent standard library. You can write simple php but it takes a lot of discipline.

> hopefully hooks will be super short and this won't be a major issue.

Even if a PHP project has a policy of short hooks, I think hooks impede clarity.

    public string $countryCode
    {
        set (string $countryCode) {
            $this->countryCode = strtoupper($countryCode);
            $this->country = nameCountry($this->countryCode);
        }
        get => ...

Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)?

Does reading `$this->countryCode` use the getter hook, even it's from a `countryCode` hook?

If not, is there a way to call the `countryCode` getter from this setter?

If quickly parsed the doc and the RFC, so I don't have answers (I suppose it's yes, no, no). But even if I knew how this code behaved, I would still think it's much more complex than plain methods.

PHP was never particularly simple, it has always had a diverse standard library and lots of similar but subtly different builtins and a rather funky type system and so on.

It's not for people that compulsively talk about category theory and lenses five minutes into every programming conversation.

Of course it's not required but when you start pushing the boundaries of a language with the goal of achieving a clean interface, obscure features you wouldn't normally resort to become appealing. I dislike all of the magic around Laravel's Eloquent ORM - model relationships, query builder, abuse of ForwardsCalls trait, etc, but at the same time I can appreciate how "clean" it all looks once it's put together.

What's magic is that `$this->foo` refers to different entities in different contexts despite the same value of `$this`, not that one of the entities to which it refers can be private.

Whenever I read about a new PHP release on HackerNews I always come away disappointed with the discussion. You are right, the "magic" that the top comment is complaining about is a non-issue, and I say that as someone who really strongly dislikes "magic" behavior.

In fact, you can imagine what their argument WOULD have been if setting `$this->countryCode` inside the setter for `countryCode` DID result in infinite recursion.

When it comes to PHP, whatever it does, on HackerNews and in the rest of the industry, it just results in a bunch of people complaining about it. Disappointing, and unprofessional.

You could prevent the recursion without this magic, by making the access a compiler error.

There are many times I would love to have an automatic backing field in C#. C# will do that if you use the default setter but in cases where that's not possible I dislike having to both declare a separate field and having it available to the rest of the class outside of the setter.

Well in python I assume it would be equivalent of accessing:

  self.__dict__['property_name']

  @property
  def property_name(self):
      return self.property_name

Lua has rawget() and rawset() to bypass the magic methods, which is used a lot inside/outside the metatables (objects with magic methods) to avoid magic loops I guess.

It might be a footgun, but it will be extremely obvious when it is triggered.

They are very useful when modeling CRUD-dy objects, because you can lazy-load infrequently-accessed child object using getters.

It makes for a cleaner OOP-y interface in which the caller only cares about actually exposed properties and not methods to get and manipulate hidden properties.

IMHO using properties directly is a much more natural way to talk about objects, than having a bunch of methods to get properties. Getters and setters also help ensure that methods are only for changing an object's state, not getting an object's state. For example:

  class User{
      public ForumsPost $LastForumsPost{
          get{
              if(!isset($this->LastForumsPost)){
                  $this->LastForumsPost = <get from database...>;
              }

              // Return the cached property so we don't keep hitting the database.
              return $this->LastForumsPost;
          }
      }
  }

  print($user->LastForumsPost->Title);
  print($user->LastForumsPost->PostId);

  // instead of...

  print(($user->GetLastForumsPost())->Title);
  print(($user->GetLastForumsPost())->PostId);

I've always been a fan because if a property turns from a simple value to a more complex interaction that might involve DB operations or other side effects then if a getter is in place you can modify the logic without needing to update widespread code.

Getters are great for manipulating data on the way out. For instance, inside the class you might store a raw representation of the data like a json string, but when reading an attribute you will decode that json string into a datastructure and pluck a certain item. I use dynamic getters often to wrap a raw value with some kind of fallback: do this if no data is present, do this if the data is present but is ancient (ie a seamless upgrade of a v1 internal datastructure to a v2 output), etc. For setters, I try not to have implicit side effects but in certain cases where it makes sense, it is nice to be able to centralize that logic: "if this value changes, ensure x and y occur" which you get "for free throughout your codebase when you use a setter, versus having to go thru the entire codebase and sprinkle the do_x() and do_y() calls (which then becomes additional footprint to maintain and worry about)

They are used in ORMs to do property value conversions from PHP primitives to values a data store might actually want.

I wrote about it here https://technex.us/2023/07/php-attributes-are-so-awesome-i-j...

The more I program the more I realize that we are all blind men feeling out an elephant.

It sounds like you got the gist but somehow you are in an area of programming where getter/setters aren't useful.

That's fine and okay. Part of growing up as a programmer is realizing your niche.

Most of the advice out there is deep, not broad. It's deeply connected with our niche and not necessarily broadly applicable.

My understanding is that PHP was sort of started by people that did not plan for it like a "serious" programming language, but rather as a tool for specific applications.

So it developed features and functionalities as needed with a very pragmatic focus [0][1]

[0] the most clear example to me is that since functions are not values and cannot be assigned to variables the way to store a function in a variable is to simply assign its name as a string so $callable = "array_map" works. Or that the way to create a pointer to a method is to create a 2 element array of the object and the method name. I like this example because the way method pointers work in JavaScript is objectively worse as the "this" is easily lost. Some languages are built on CS principles and PL theory, others like Bash or PHP are just built to get shit done. I am glad that recent versions are fixing some of the oversight of this approach while keeping the pragmatic culture

[1] I am not sure of how true it is, but some claim that some of the standard functions have irregular names because the interpreter used the name length as hash key

> more airbags, for the bad code

Great metaphor. I might steal it for some model contract terms I'm doing (for an expanded version of my contract-drafting course materials). I'd been thinking of "guardrails," but "airbags" is far better.

I dunno, we just about got rid of the whole "cosmic rays" discussions for computers and finally are getting realistic about the bugs that occur in computers are from bad C code and bad hardware. Neither of those things are easy to use and they have done probably more damage than crappy php code does.

> With predictable results.

People building and creating awesome new things? Increase in happiness and empowerment? More efficient processes and increase in productivity? New businesses being born? Wealth and value being added to society?

This varies by domain of course, but on the web (PHP's domain), the language in greatest use nowadays by professional programmers is....Javascript.

What a condescending point of view.

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.

An IDE can help you write the code, but does not make it easier to read the code.

"if not defined" doesn't help, if your own `array_find` doesn't have the same signature and semantics than the new global then you're screwed. You'd want the opposite: overwrite it if it already exists in the global scope (dunno if that's easy / how that'd work in PHP)

For a project like Wikipedia, stability and continuity are far more important than latest and greatest feature support; in fact, there's an argument to be made to avoid newer language features to ensure consistency, that is, if new features are used, they should be used everywhere at once. Else you end up with frankenstein code where every file could use a different style.

8.2 and 8.3, respectively.

I enjoy the PHP 8 new features such as named arguments, constructor arguments promotion and nullsafe operators. Made my new code a lot more readable.

I am not that sure about 8.4 yet, though the new array_ functions and new DOM look interesting.

Didn't PHP 5 stop getting security updates more six or seven years ago?

I guess depending on the app that might not really matter, but that seems like it could be an issue at some point.

Sure, and I'm still using PHP every once in a while for personal needs (I have a handful of small personal websites built this way: PHP has this insanely cool capability of being just a scripting language for a basic dynamic website).

What's sad is that it's not how people use and teach PHP today.

PHP's magic really is that you can write small scripts super easily to do small tasks, but somehow most PHP developers insist that “no PHP isn't for building small scripts” but “a real, professional back end language ready for mission critical enterprise requirements blah blah blah”, because surely that make them sound more serious as programmers, missing the point entirely…

(And sorry to all insecure PHP programmers out there, but for serious stuff using PHP is still equivalent to coding with handcuffs and you should really learn a second programming language at last because being a one trick poney really isn't as cool as you think it is).

Java doesn't force you into that paradigm either. Well, most of it. Your code is still contained within a method within a class.

If you write JSP, you don't even need that.

I still do, every once in a while when I'm using PHP for my personal websites, but it's been a very long time since I've updated the (very basic) dependencies I'm using since they all migrated to the “enterprise-grade tooling of the day” after 2010 or something.

While PHP can still be uses like that today (and is still unmatched in terms of ease of use for simple stuff when used like that) it's been a long time since the PHP project and developer community stopped caring about this use-case.

Zend offerings are confusing. https://www.zend.com/services/php-long-term-support only lists 8.0 and earlier, https://www.zend.com/products/zendphp-enterprise does have a chart showing 8.3 into 2029 but once again the text only mentions 8.0. What gives?

They could help by not adding any more cruft to the global namespace.

Adding any globals should be a carefully-considered change. User-defined functions are global by default, and although there are (now) much better ways to write PHP libraries, I can absolutely see some old library defining array_find (one of the new global functions in 8.4) in an incompatible way and breaking new code that attempts to use the built-in function.

Sure, you can’t touch the existing pile of globals, but at least stop pouring fuel on that particular fire…

I think the bigger issue is that these lessons have already been learned. However, PHP (Personal Home Page) was not created carefully by someone to become a fully fledged language. It grew into that role organically which is why it has so many warts in hindsight.

There is a RFC on it (https://wiki.php.net/rfc/function-composition) which I'd love if it made it through. Until then Crell's FP library is a good option (https://github.com/Crell/fp).

It could be much easier for user defined functions to collide with standard functions, especially when it happens unintentionally.

Someone else creates a function named array_something in the namespace. Maybe it already exists in earlier versions, maybe it happens to collide with one of the four introduced in 8.4. This function is accessible to you in the current scope. Now, you try to call the function like the way it is defined in the standard library. You get a very confusing error and spend 10 minutes trying to figure if it is you or PHP that is hallucinating. Turns out you have been inadvertently calling that other user defined function. The other user may be completely unaware of the fact that they created a function with naming collision.

To combat this, you need strong IDE help including static type checking, which is not always there for everybody. And it still doesn't help with cases where the user defined function collides with a new standard function.

Most "modern" languages have very few built-in functions in the global namespace. Another example is Go. Correct me if I am wrong, but I believe there is 0 function in global namespace in Rust. println! exists but that's a macro. In other words, the example I mentioned just never happens with these languages.

Not to mention the long list of junk you see in IDE when you type "array_".

I guess you haven't written much MATLAB.

Sir, PHP can fly.

- https://www.php.net/manual/en/book.ffi.php

While I'm at it:

- https://pecl.php.net/package/tensor

- https://rubixml.com/

- https://github.com/RubixML/Tensor

Link those benchmarks please. Both 500 and 10k-30k seem extremely low.

There are of course ways to get "reload page, see results" to work even with Python. After all, computers are touring complete.

But in PHP you have it out of the box. Faster, with less complexity and less resource consumption. And you can use the same setup in development as you can use in production.

To get to know Laravel, I forced myself to build a project with it for a few weeks and I did not like it.

I found myself getting sucked in into a complex project structure and dealing with all kinds of strangeness like "artisan commands", "the autoload cache" etc.

With Django, I can build a web application in a single file that has "import django" on top and take it from there:

https://news.ycombinator.com/item?id=40788329

It’s difficult for me to trust a framework backed by venture capital (https://blog.laravel.com/accel-invests-57m-into-laravel). There are too many incentives to prioritize making money, which makes it easy to overlook developer experience. I rather use Symfony instead.

I much prefer Symfony, but that's mainly because it's the framework I started with.

I had hoped to forget

> I know people love to say this, but does anyone realistically make websites or web apps that way?

In PHP, I do. In other platforms, no. My personal PHP site is published by a git push to the server.

I do it all the time, thank you very much. For a simple web app I don't even need a framework - you can literally create a simple files/folder structure, include files, include folders and get stuff done. An yeah, you can also upload the files by FTP. For something more complicated I'd use WP or Code Igniter depending on the specific project. And then you can again just SFTP those files to the server.

>but does anyone realistically make websites or web apps that way?

You are correct in that a lot of PHP use now is larger frameworks with asset compilation and cache clearing etc, but even when developing on large systems like that it is nice to sometimes be able to just manually tweak a file and refresh.

For R&D and quick tests, just uploading a quick & dirty php file to the server is a very useful language feature to have IMO.

.. and as soon as you stop just uploading files (which, as you say, nobody does), a lot of the other advantages go away also. Laravel and Symphony both make PHP much slower. If you are going to have sane routing, you're probably going to need to tweak your websever to behave, well, less like a web server. There's a decent chance you'll need to clear a cache after you upload your changed files if you want to actually see those changes.

I actually like PHP a lot, and it's amazing how far it has come in the past 10 or so years, I just think way too many people assume you get the 2004-era PHP simplicity with all of the 2024-era PHP refinements, and you really don't. There's tradeoffs.

They just added extension support to packagist, so composer looks like a pretty healthy ecosystem that's officially supported.

https://thephp.foundation/blog/2024/11/19/pie-pre-release/

> Python’s packaging and dependencies system is lacking

It is? I never had problems with poetry. Though I agree that there are mroe options than necessary.

Most PHP apps use a deployment method where a symlink gets set to a directory with a new version of the code. Because of how opcache works this has no impact on running requests, while new requests get handled with the new code.

You can use the same strategy with PHP. Preload all your scripts in opcache. Once you're done making changes, reset your opcache.

In practice, any serious project is likely to be version-controlled. Git pull is generally fast enough that it behaves like an atomic change. (By default, opcache will not reload a file that's less than 2 seconds old.)

Not sure where you got that from. It’s equally if not faster then python, faster then Java, slower then compiled language, faster then ruby. Loses to NodeJS most of the time.

But who cares, we are literally talking millisecond differences between them all. Throw a reverse proxy, DB into the mix and a few packages and they are all slow.

It could have been, but isn’t. Most of those are rather small, incremental quality-of-life improvements. Nothing revolutionary.