rfc:case_insensitive_constant_deprecation

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
rfc:case_insensitive_constant_deprecation [2018/06/24 11:07] – Move to under discussion nikicrfc:case_insensitive_constant_deprecation [2018/06/24 12:18] – nikic
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 incorrect 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 =====
rfc/case_insensitive_constant_deprecation.txt · Last modified: 2018/07/16 17:18 by nikic

Page Tools