WordPress.org

Make WordPress Core

Changes between Version 1 and Version 2 of Ticket #33381, comment 42


Ignore:
Timestamp:
08/17/2015 06:02:01 PM (4 years ago)
Author:
alexander.rohmann
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #33381, comment 42

    v1 v2  
    662. Longevity. Generally speaking, the farther you lag behind the harder it is to catchup.
    773. 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.
     84. 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.
    109
    1110> 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.