rfc:namespaces_in_bundled_extensions

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:namespaces_in_bundled_extensions [2021/04/14 14:16] nikicrfc:namespaces_in_bundled_extensions [2021/05/03 08:01] (current) nikic
Line 2: Line 2:
   * Date: 2021-02-25   * Date: 2021-02-25
   * Author: Nikita Popov <nikic@php.net>   * Author: Nikita Popov <nikic@php.net>
-  * Status: Under Discussion+  * Status: Accepted
   * Target Version: PHP 8.1    * Target Version: PHP 8.1 
  
Line 83: Line 83:
 The distinction between these three extensions is somewhat murky from an end-user perspective, and largely historical. Symbols have moved between these extensions, e.g. the ''Iterator'' interface originated in spl, but now lives in Core. The distinction between these three extensions is somewhat murky from an end-user perspective, and largely historical. Symbols have moved between these extensions, e.g. the ''Iterator'' interface originated in spl, but now lives in Core.
  
-Because these extensions combine a lot of unrelated or only tangentially related functionality, symbols should not be namespaced under the ''Core'', ''Standard'' or ''Spl'' namespaces. Instead these extensions should be considered as a collection of different components, and should be namespaced according to these.+Because these extensions combine a lot of unrelated or only tangentially related functionality, symbols should not be namespaced under the ''Core'', ''Standard'' or ''Spl'' namespaces. Insteadthese extensions should be considered as a collection of different components, and should be namespaced according to these.
  
-For example, ''str_contains()'' could become ''String\contains()'', ''in_array()'' could become ''Array\contains()'', and ''password_hash()'' could become ''Password\hash()''.+For example, ''str_contains()'' could become ''Str\contains()'', ''fopen()'' could become ''File\open()'', and ''password_hash()'' could become ''Password\hash()''(These are non-normative examples, the RFC does not propose using these specific namespaces.)
  
 ==== Existing non-namespaces symbols and consistency ==== ==== Existing non-namespaces symbols and consistency ====
Line 91: Line 91:
 When adding new symbols to existing extensions, it is more important to be consistent with existing symbols than to follow the namespacing guidelines. When adding new symbols to existing extensions, it is more important to be consistent with existing symbols than to follow the namespacing guidelines.
  
-For example, the ''array_is_list()'' function added in PHP 8.1 should indeed be called ''array_is_list()'' and should not be introduced as ''Array\is_list()''. Unless and until existing ''array_*()'' functions are aliased under the ''Array\*'' namespace, new additions should continue to be of the form ''array_*()'' to maintain horizontal consistency.+For example, the ''array_is_list()'' function added in PHP 8.1 should indeed be called ''array_is_list()'' and should not be introduced as ''Array\is_list()'' or similar. Unless and until existing ''array_*()'' functions are aliased under an ''Array\*'' namespace, new additions should continue to be of the form ''array_*()'' to maintain horizontal consistency.
  
 This is a somewhat loose guideline, and applies more strongly to functions than classes. In particular, when new object-oriented elements are introduced into an extension that has historically been procedural, these may be namespaced. For example, if ''OpenSSLCertificate'' had only been introduced in PHP 8.1, it should have been named ''OpenSSL\Certificate''. This is a somewhat loose guideline, and applies more strongly to functions than classes. In particular, when new object-oriented elements are introduced into an extension that has historically been procedural, these may be namespaced. For example, if ''OpenSSLCertificate'' had only been introduced in PHP 8.1, it should have been named ''OpenSSL\Certificate''.
Line 97: Line 97:
 For the Core/standard/spl extensions, the previous considerations on component subdivision apply. The fact that string and array functions are not namespaced does not preclude new namespaced components in these extensions. For the Core/standard/spl extensions, the previous considerations on component subdivision apply. The fact that string and array functions are not namespaced does not preclude new namespaced components in these extensions.
  
-==== Migration of existing symbols ====+==== Namespace collisions ====
  
-Migration of existing symbols to use namespaces is considered out of scope for this RFC. This RFC is only concerned with the namespacing of new symbols.+The disadvantage of not using a vendor namespace is that namespace collisions are more likely. A mitigating factor is the pervasive use of vendor namespaces in the userland ecosystem (in which case the collision would have to be between a vendor namespace and a component namespace, which is less likely). 
 + 
 +As a matter of courtesy, top-level namespaces used by extensions should avoid collisions with existing, commonly used open-source libraries or extensions (or happen with the agreement of the parties involved). This RFC does not try to provide a hard guideline on what constitutes a sufficiently important library. The application of common sense is recommended.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
  
 None. None.
 +
 +===== Future Scope =====
 +
 +This RFC only officially allows use of namespaces, and provides basic guidelines for their use. However, it does not propose to migrate already existing non-namespaced symbols to use namespaces. Such a migration should be the subject of a separate RFC.
  
 ===== Vote ===== ===== Vote =====
  
-Yes/No.+Voting started 2021-04-19 and ended 2021-05-03. 
 + 
 +<doodle title="Allow use of namespaces in line with these guidelines?" auth="nikic" voteType="single" closed="true"> 
 +   Yes 
 +   No 
 +</doodle>
  
rfc/namespaces_in_bundled_extensions.1618409796.txt.gz · Last modified: 2021/04/14 14:16 by nikic