Changes between Version 1 and Version 2 of Ticket #33381, comment 42
- Timestamp:
- 08/17/2015 06:02:01 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33381, comment 42
v1 v2 6 6 2. Longevity. Generally speaking, the farther you lag behind the harder it is to catchup. 7 7 3. Ostracizing developers, who are getting more and more frustrated. It's difficult for plugins to integrate with services these days. Vendor libraries for their APIs follow modern PHP development. This leaves us to develop our own library to interface with an API if we want to comply with 5.2. 8 9 Obviously there's no point to refactoring just for the sake of refactoring, but core is consistently developing features and refining old ones so there would be places to introduce refined development practices in core itself. Even new features have so many workarounds to simple problems that can be solved with newer PHP concepts. For example: "late static bindings" ( introduced in PHP 5.3 so it's hardly new) would could solve so many inheritance issues, that lead to repeating code. 8 4. Improving development of new core features. Obviously there's no point to refactoring just for the sake of refactoring, but core is consistently developing features and refining old ones so there would be places to introduce refined development practices in core itself. Even new features have so many workarounds to simple problems that can be solved with newer PHP concepts. For example: "late static bindings" ( introduced in PHP 5.3 so it's hardly new) would could solve so many inheritance issues, that lead to repeating code. 10 9 11 10 > There by the way is already a mechanism in WordPress and WordPress.org that is being used to not serve new major versions to unsupported PHP installs, so there's no need for a discussion on implementation of that; it already exists, and is already in use.