rfc:case_insensitive_constant_deprecation

Differences

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

Link to this comparison view

Next revision		Previous revision
Next revisionBoth sides next revision
rfc:case_insensitive_constant_deprecation [2018/06/24 11:00] – created nikicrfc:case_insensitive_constant_deprecation [2018/06/24 12:18] – nikic
Line 4: Line 4:
   * Target PHP version: PHP 7.3   * Target PHP version: PHP 7.3
   * Implementation: https://github.com/php/php-src/pull/3321   * Implementation: https://github.com/php/php-src/pull/3321
-  * Status: Draft+  * Status: Under Discussion
  
 ===== Introduction ===== ===== Introduction =====
Line 12: Line 12:
 The current state of the matter is: The current state of the matter is:
  
-  * Class constants are always case-insensitive.+  * Class constants are always case-sensitive.
   * Global constants declared with ''const'' are always case-sensitive. It should be noted that this applies only to the shortname of the constant, while namespaces in PHP are always case-insensitive.   * Global constants declared with ''const'' are always case-sensitive. It should be noted that this applies only to the shortname of the constant, while namespaces in PHP are always case-insensitive.
   * Constants declared with ''define()'' are case-sensitive by default.   * Constants declared with ''define()'' are case-sensitive by default.
Line 74: Line 74:
 This is an issue that can in principle be resolved, however it would come with significant additional implementation complexity and a hit to performance and memory usage. At the least, it would require storing lower-cased variants of all constants and checking against them on new constant declarations. This is an issue that can in principle be resolved, however it would come with significant additional implementation complexity and a hit to performance and memory usage. At the least, it would require storing lower-cased variants of all constants and checking against them on new constant declarations.
  
-==== Implementation overhead ====+==== Implementation complexity and overhead ====
  
 Support for case-insensitive constants makes the implementation more complex and slower. Constant lookups are implemented by first looking up the constant name directly, and then looking up a lowercased variant. Support for case-insensitive constants makes the implementation more complex and slower. Constant lookups are implemented by first looking up the constant name directly, and then looking up a lowercased variant.
  
-A particularly extreme case are access to unqualified constants inside namespaces. For example, if constant ''FOO'' is accessed inside namespace ''NS'', the ''FETCH_CONST'' opcode is created with a record-breaking five literals. In order, ''foo\NS'', ''foo\ns'', ''FOO'' and ''foo'' need to be looked up, and finally ''FOO\NS'' is used for error-reporting. For the common case where the intended constant was ''FOO'' this results in three lookups. Thankfully the impact is mitigated by runtime caching (which is actually illegal due to the previous point).+A particularly extreme case are access to unqualified constants inside namespaces. For example, if constant ''FOO'' is accessed inside namespace ''NS'', the ''FETCH_CONST'' opcode is created with a record-breaking five literals. In order, ''ns\FOO'', ''ns\foo'', ''FOO'' and ''foo'' need to be looked up, and finally ''NS\FOO'' is used for error-reporting. For the common case where the intended constant was ''FOO'' this results in three lookups. Thankfully the impact is mitigated by runtime caching (which is actually incorrect due to the previous point).
      
 ===== Proposal ===== ===== Proposal =====
Line 90: Line 90:
 </code> </code>
  
-The ''defined()'' function is not affected. It will continue to return ''true'' for case-sensitive constants, without generating a deprecation warning.+The ''defined()'' function is not affected. It will continue to return ''true'' for case-insensitive constants, without generating a deprecation warning.
  
 Declaration of case-insensitive constants by extensions will not generate a deprecation warning (though their access will). The reason behind this is that the end-user will not be able to do anything about this deprecation warning, while the extension maintainer may not be able to change the declaration for BC reasons at this point. Declaration of case-insensitive constants by extensions will not generate a deprecation warning (though their access will). The reason behind this is that the end-user will not be able to do anything about this deprecation warning, while the extension maintainer may not be able to change the declaration for BC reasons at this point.
rfc/case_insensitive_constant_deprecation.txt · Last modified: 2018/07/16 17:18 by nikic

Page Tools