4 ms·

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.

by cutler 2y ago

klaussilveira 2y ago
Yes, that is correct. And this release marks a point where the language is officially moving away from that.
- thrw42A8N 2y ago
  How? It just got way more invested into OOP... It's now much harder to understand my code at a glance. The Java feeling isn't because I have to write a lot of code, it's how the code works.
  - stephenr 2y ago
    > It's now much harder to understand my code at a glance. Why? Property hooks aren't mandatory. If you want to keep using explicit getter/setter methods, you can do that. If you want to keep using implicit getter/setter hooks via __get/__set, you can do that. If you want to keep using plain property access, you can do that. All this does, is allow features that previously relied on the black box of __get/__set to be exposed as real properties. This massively improves the scenario for anything that works via reflection, and makes a whole suite of bugs related to unintended behaviour, simply impossible.
    - thrw42A8N 2y ago
      Others will use them and I will need to use their libraries. Get and set magic methods were a mistake too. Same with reflection. Again and again, deeper into the Java 6-land, while Java itself went away a decade ago.
      - stephenr 2y ago
        > Others will use them and I will need to use their libraries. From the outside it's just a property access. The whole point is you don't need to worry about whether it's a direct access or a getter/setter with logic, even if it changes from one to the other between versions. > Get and set magic methods were a mistake too. They're definitely not ideal, and thanks to this change they're no longer required for the vast majority of cases. > Same with reflection. Reflection is a mistake?
        thrw42A8N 2y ago
        I need to worry about it if I'm using it in an app. In what job you don't need to worry about what code are you executing? This is the whole point. It makes my job much harder to do, much more hidden and arcane - not worth it to save few characters. Yes, reflection is a mistake. It's a hotfix for problems caused by OOP. It's not actually necessary. TypeScript is a good example. Some people write it like Java/C#, with classes, inheritance, reflection, dependency injection. Usually I can get that code down to 20-30% of original size after I cut out the last class (then I forbid the keyword in linter), and none of that is actually necessary or improved the situation.
        stephenr 2y ago
        > In what job you don't need to worry about what code are you executing? Worry about? Or understand the fine minutia of how every property you fetch or store is handled? > It makes my job much harder to do, much more hidden and arcane I don't know how you do your job, but seeing a real (i.e. not a faux property handled by __get/__set) class member's implementation is literally 1 click away in any decent IDE. Clicking to see the potential hooks of a field vs clicking to see the getter or setter (which may or may not even be defined in the same class) is no different. > Yes, reflection is a mistake. It's a hotfix for problems caused by OOP. It's not actually necessary. Right. I guess that's why it's applicable to functional programming. To be a hotfix for OOP? https://www-master.ufr-info-p6.jussieu.fr/2007/Ajouts/Master_esj20_2007_2008/IMG/pdf/malenfant-ijcai95.pdf https://www-master.ufr-info-p6.jussieu.fr/2007/Ajouts/Master...

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.

by cutler 2y ago

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.

klaussilveira 2y ago

Yes, that is correct. And this release marks a point where the language is officially moving away from that.

thrw42A8N 2y ago
How? It just got way more invested into OOP... It's now much harder to understand my code at a glance. The Java feeling isn't because I have to write a lot of code, it's how the code works.
- stephenr 2y ago
  > It's now much harder to understand my code at a glance. Why? Property hooks aren't mandatory. If you want to keep using explicit getter/setter methods, you can do that. If you want to keep using implicit getter/setter hooks via __get/__set, you can do that. If you want to keep using plain property access, you can do that. All this does, is allow features that previously relied on the black box of __get/__set to be exposed as real properties. This massively improves the scenario for anything that works via reflection, and makes a whole suite of bugs related to unintended behaviour, simply impossible.
  - thrw42A8N 2y ago
    Others will use them and I will need to use their libraries. Get and set magic methods were a mistake too. Same with reflection. Again and again, deeper into the Java 6-land, while Java itself went away a decade ago.
    - stephenr 2y ago
      > Others will use them and I will need to use their libraries. From the outside it's just a property access. The whole point is you don't need to worry about whether it's a direct access or a getter/setter with logic, even if it changes from one to the other between versions. > Get and set magic methods were a mistake too. They're definitely not ideal, and thanks to this change they're no longer required for the vast majority of cases. > Same with reflection. Reflection is a mistake?
      - thrw42A8N 2y ago
        I need to worry about it if I'm using it in an app. In what job you don't need to worry about what code are you executing? This is the whole point. It makes my job much harder to do, much more hidden and arcane - not worth it to save few characters. Yes, reflection is a mistake. It's a hotfix for problems caused by OOP. It's not actually necessary. TypeScript is a good example. Some people write it like Java/C#, with classes, inheritance, reflection, dependency injection. Usually I can get that code down to 20-30% of original size after I cut out the last class (then I forbid the keyword in linter), and none of that is actually necessary or improved the situation.
        stephenr 2y ago
        > In what job you don't need to worry about what code are you executing? Worry about? Or understand the fine minutia of how every property you fetch or store is handled? > It makes my job much harder to do, much more hidden and arcane I don't know how you do your job, but seeing a real (i.e. not a faux property handled by __get/__set) class member's implementation is literally 1 click away in any decent IDE. Clicking to see the potential hooks of a field vs clicking to see the getter or setter (which may or may not even be defined in the same class) is no different. > Yes, reflection is a mistake. It's a hotfix for problems caused by OOP. It's not actually necessary. Right. I guess that's why it's applicable to functional programming. To be a hotfix for OOP? https://www-master.ufr-info-p6.jussieu.fr/2007/Ajouts/Master_esj20_2007_2008/IMG/pdf/malenfant-ijcai95.pdf https://www-master.ufr-info-p6.jussieu.fr/2007/Ajouts/Master...