rfc:namespace_scoped_declares

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:namespace_scoped_declares [2017/12/11 12:54] – nikicrfc:namespace_scoped_declares [2022/01/25 18:22] (current) – Move to inactive ilutov
Line 4: Line 4:
   * Author: Nikita Popov <nikic@php.net>   * Author: Nikita Popov <nikic@php.net>
   * Proposed PHP version: PHP 7.3   * Proposed PHP version: PHP 7.3
-  * Status: Under Discussion+  * Status: Inactive
   * PR: https://github.com/php/php-src/pull/2972   * PR: https://github.com/php/php-src/pull/2972
   * ML thread: http://externals.io/thread/326   * ML thread: http://externals.io/thread/326
Line 124: Line 124:
  
 This restriction is introduced for two reasons: Firstly, lack of such a restriction would imply that language behavior can silently change in the middle of a single file, which would be very confusing. Secondly, there are are significant implementational complexities associated with allowing this type of code due to limitations of specific declare directives. In particular the current implementation of ''strict_types'' only permits a consistent ''strict_types'' value for a whole file. Lifting the declare-consistency requirement would require changing the ''strict_types'' implementation to support this and, more importantly, commitment to support this for all future declare directives we introduce, which may be non-trivial. This restriction is introduced for two reasons: Firstly, lack of such a restriction would imply that language behavior can silently change in the middle of a single file, which would be very confusing. Secondly, there are are significant implementational complexities associated with allowing this type of code due to limitations of specific declare directives. In particular the current implementation of ''strict_types'' only permits a consistent ''strict_types'' value for a whole file. Lifting the declare-consistency requirement would require changing the ''strict_types'' implementation to support this and, more importantly, commitment to support this for all future declare directives we introduce, which may be non-trivial.
 +
 +==== Supported declare directives ====
 +
 +Currently PHP supports three declare directives, ''ticks'', ''strict_types'' and ''encoding''.
 +
 +''namespace_declare()'' does not support ''encoding'' and will generate an ''Error'' if it is specified. The reason is that ''encoding'' has very special semantics, and requires the directive to be resolved already at parse-time, so that the lexer behavior may be influenced. At the point where the first namespace is encountered, it may already be too late to act on this directive.
 +
 +For ''ticks'' the passed value must be a non-negative integer, otherwise an ''Error'' is thrown.
 +
 +For ''strict_types'' the passed value must be integer ''0'' or ''1'', otherwise an ''Error'' is thrown.
  
 ==== Open Question: Handling of unknown directives ==== ==== Open Question: Handling of unknown directives ====
Line 130: Line 140:
  
 If we go for throwing a warning here, it might be beneficial to add a ''supports_declare()'' function, which allows you to determine whether a certain declare directive is supported, without resorting to a PHP version check (which would likely be unreliable with regard to alternative PHP implementations). If we go for throwing a warning here, it might be beneficial to add a ''supports_declare()'' function, which allows you to determine whether a certain declare directive is supported, without resorting to a PHP version check (which would likely be unreliable with regard to alternative PHP implementations).
 +
 +==== Open Question: Introspection functionality ====
 +
 +It might be useful to also provide a mechanism to retrieve the active namespace-scoped declares at runtime, e.g. using a ''get_namespace_declares()'' function. One could either make this return the declarations for all namespaces exactly as given, or return the computed declarations for a specific namespace. I'm not sure what the specific use-case for this kind of introspection functionality would be, though.
  
 ==== Implementation considerations ==== ==== Implementation considerations ====
  
 Declare directives have to be known at compile-time, because they may directly influence the emitted opcodes. Files will always be compiled for the current declare configuration and opcache will cache them for that specific configuration. Opcache additionally stores which namespaces and namespace-scoped declares are used and will verify that the (relevant) namespace-scoped declares did not change when the file is loaded again. If the (relevant) namespace-scoped declares changed, the file will be invalidated and compiled again for the new configuration. Declare directives have to be known at compile-time, because they may directly influence the emitted opcodes. Files will always be compiled for the current declare configuration and opcache will cache them for that specific configuration. Opcache additionally stores which namespaces and namespace-scoped declares are used and will verify that the (relevant) namespace-scoped declares did not change when the file is loaded again. If the (relevant) namespace-scoped declares changed, the file will be invalidated and compiled again for the new configuration.
- 
  
 ===== Disadvantages ===== ===== Disadvantages =====
Line 145: Line 158:
  
 Additionally it should be noted that the same problem (to an even worse degree) exists for the ini system, where ini options can be specified from many different sources (including multiple ini files, htaccess files and inline in PHP code). In practice this does not appear to be a major problem. Additionally it should be noted that the same problem (to an even worse degree) exists for the ini system, where ini options can be specified from many different sources (including multiple ini files, htaccess files and inline in PHP code). In practice this does not appear to be a major problem.
 +
 +Finally, while namespace-scoped declares may be less explicit, they fit better into the mental model we use as programmers. Libraries generally do not haphazardly switch between different strict_types files and instead use a consistent mode for the entire project. Namespace-scoped declares codify this and prevent mistakes like forgetting to add a declare directive when creating a new file.
  
 ==== Proliferation of declare directives ==== ==== Proliferation of declare directives ====
Line 157: Line 172:
  
 Nonetheless, I think that proliferation of declare directives is a real danger and we need to ensure that new directives are not added frivolously. Nonetheless, I think that proliferation of declare directives is a real danger and we need to ensure that new directives are not added frivolously.
 +
 +==== Discussion: Potential for abuse ====
 +
 +One issue that came up repeatedly during the first discussion, is that people perceived a potential for abuse in this feature. The concern is that it would be possible to call ''namespace_declare()'' on a namespace one doesn't own, and consequently break code using that namespace.
 +
 +I honestly do not understand this concern. PHP is already oversaturated with ways in which you could break external library code if one wants to (such as hijacking autoloading). If breaking library code is your goal, you don't need this feature to achieve that. However, the question remains why anyone would want to this, as in the end you only sabotage yourself.
  
 ===== Alternatives ===== ===== Alternatives =====
Line 180: Line 201:
  
   * Resolve open question "Handling of unknown directives"   * Resolve open question "Handling of unknown directives"
-  * Consider adding some introspection functionality, such as ''get_namespace_declares()'' +  * Resolve open question "Introspection functionality"
-  * Investigate whether this mechanism can support the ''encoding'' directive, which is a lot more magic than the rest.+
rfc/namespace_scoped_declares.1512996896.txt.gz · Last modified: 2017/12/11 12:54 by nikic

Page Tools