On 24-03-2020 10:21, Máté Kocsis wrote: > Hi Larry, > > In my opinion, one of the core assets of PHP is that it contains relatively > few syntactic sugar compared > to some other languages, e.g. C#. Maybe it's just me, but I believe it > makes the code written in PHP > easier to read. And I think this is what we should optimize for. Not for > saving a few lines of code, > but for making the code easier to read and understand.
It's not just you. :) I fully agree with you here. PHP has a straight, down-to-earth character with very little magic going on. This is what makes the code easy to understand and debug. I just would not use the term 'syntactic sugar' in this context. To me, syntactic sugar has a positive connotation: A nicer way to express the same thing that is easier to read. Magic is making things happen in non-obvious ways that are easily missed when looking at the code. Magic can look really attractive, until something does not work as expected and you fail to see why. Python code tends to have tons of it. The point where sugar ends and magic begins is a matter of taste. To me, constructor promotion tends slightly towards magic. But then, anyone can choose to use the feature or not. > To be honest, my impression is that most of the problems you list (e.g. > verbose constructor, bean problem, > or even property accessors) mainly boil down to the verbosity of PHP (or > the "visual debt" problem > how some people calls it). As I wrote in the first paragraph, I don't think > it's a bad thing. Reducing verbosity is not the problem. Introducing magic is. While property accessors are magic, they are a form of magic that I would be willing to accept, for the following reasons. A nice feature of accessors is that they allow swapping a traditional public class property for a property accessor without changing API. Such a feature currently has little value, because public properties are not commonly used because they cannot be marked as read-only yet. Once public class properties can be marked read-only I would be comfortable exposing them directly, without writing any getters and setters for them. The only thing that would still worry me is: What if I need to add some form of access logic later on? Property accessors allow me to do this without introducing a BC break. So yes, property accessors are magic. However, in combination with read-only properties they would allow for dropping tons of getter methods and directly expose properties in stead. They allow this because they are the 'safety net' which makes me comfortable doing it. We get more PHP and less Java. This probably means that I will occasionally have to actually use property accessors at some point and introduce a bit of magic. Then, it still isn't the worst possible magic. Accessors are explicitly declared on the class, an editor could easily show me that accessing a particular property calls a method and show me the code. It's not ideal but it's not that bad either. > But I don't understand why is would be a good thing to have two types of > methods? How should we decide if we > should use normal methods or property accessors? I think the current I would prefer to only use accessors to add logic to property access without introducing a BC break. A successor to using __get() and __set(). For access logic that is obviously non-trivial from the start I would probably continue to use regular getter and setter methods. > I still don't think that property accessors would solve the main use-case > of "write-once" properties. Indeed. For that purpose I would prefer a keyword for marking a public property as read-only. Regards, Dik Takken -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
