rfc:platform_requirement_declares

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
rfc:platform_requirement_declares [2020/02/16 11:17] – created marandallrfc:platform_requirement_declares [2020/02/16 15:23] (current) – marandall
Line 1: Line 1:
 ====== PHP RFC: Platform Requirement Declares ====== ====== PHP RFC: Platform Requirement Declares ======
   * Version: 0.1   * Version: 0.1
-  * Date: 2013-02-24 (use today's date here)+  * Date: 2020-02-16
   * Target: PHP 8.0   * Target: PHP 8.0
   * Author: Mark Randall, marandall@php.net   * Author: Mark Randall, marandall@php.net
Line 24: Line 24:
 I suggest that the sooner we add support for this declare (even if only suppressing the compile warning that would come with it on earlier versions) the sooner we have options available to provide both safety from unintended consequences due to running on prior versions, and the option to implement new features while preserving backwards compatibility for those files which have not stated their intent to use newer behaviour. I suggest that the sooner we add support for this declare (even if only suppressing the compile warning that would come with it on earlier versions) the sooner we have options available to provide both safety from unintended consequences due to running on prior versions, and the option to implement new features while preserving backwards compatibility for those files which have not stated their intent to use newer behaviour.
  
 +
 +===== Why not composer? =====
 +Composer ​repositories have the ability to check packages against certain requirements,​ including the PHP version. However, this is only performed when the vendor directory is installed or updated, meanwhile the PHP version ​is free to change independently,​ either through being installed on the server, or the source code itself being moved. 
 +
 +Crucially, if Composer handles this of its own accord, that information is not exposed to PHP, and therefore the engine will be unable to make decisions based upon it (see future scope).
 + 
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 30: Line 36:
  
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
-This would target PHP 8.0, although as a small preemptive change, discussions could be had about backporting a limited version to 7.4 that would suppress the error.+This would target PHP 8.0, although as a small preemptive change, discussions could be had about back-porting a limited version to 7.4 that would suppress the error.
  
  
Line 36: Line 42:
 This RFC is laying the groundwork for the language to take decisions based on the file authors stated version. To that end it may be beneficial to expose the platform_target to the execution context by storing it against functions / opcodes so it can be read as part of the execute data. This RFC is laying the groundwork for the language to take decisions based on the file authors stated version. To that end it may be beneficial to expose the platform_target to the execution context by storing it against functions / opcodes so it can be read as part of the execute data.
  
-This opens the door for limiting backwards compatibility issues by only making certain changes when targetting versions xx.yy or above. +This opens the door for limiting backwards compatibility issues by only making certain changes when targeting versions xx.yy or above.  
 + 
 +This would mean that new breaking changes could be made by allowing programmers to opt-in, meanwhile those without platform targets, or those with a platform target less than the version the breaking change was introduced, could continue to receive historic behaviour, with a deprecation notice giving an approximate date at which point the new behaviour will be considered default.
  
rfc/platform_requirement_declares.1581851828.txt.gz · Last modified: 2020/02/16 11:17 by marandall

Page Tools