rfc:sealed_classes
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:sealed_classes [2022/03/02 23:57] – azjezz | rfc:sealed_classes [2022/04/01 08:21] (current) – closed vote azjezz | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== PHP RFC: Sealed Classes ====== | ====== PHP RFC: Sealed Classes ====== | ||
* Date: 2021-04-24 | * Date: 2021-04-24 | ||
- | * Author: Saif Eddin Gmati < | + | * Author: Saif Eddin Gmati < |
- | * Status: | + | * Status: |
* Target Version: PHP 8.2 | * Target Version: PHP 8.2 | ||
* First Published at: https:// | * First Published at: https:// | ||
Line 169: | Line 169: | ||
1. shared functionality | 1. shared functionality | ||
- | Sealed classes feature allow you to implement functionalities in the is common between sub-types, such as: | + | Sealed classes feature allow you to implement functionalities in the parent class, such as: |
< | < | ||
Line 247: | Line 247: | ||
The output of `consumer` could be either `" | The output of `consumer` could be either `" | ||
- | |||
===== Syntax ===== | ===== Syntax ===== | ||
Line 285: | Line 284: | ||
trait Corge for Grault, Garply {} | trait Corge for Grault, Garply {} | ||
</ | </ | ||
+ | |||
+ | |||
+ | ===== FAQ's ===== | ||
+ | |||
+ | == Wouldn' | ||
+ | |||
+ | No, a sealed class will always have a `permits` clauses, if a sealed class is defined without a `permits` clauses, it's considered | ||
+ | a compile error. | ||
+ | |||
+ | |||
+ | == Would PHP check if permitted classes exists when loading a sealed class? == | ||
+ | |||
+ | No, when loading a sealed class, PHP would treat just like any other class, and store the permitted types list to check against | ||
+ | later when another type tries to inherit from it. | ||
+ | |||
+ | == What if the permitted types don't actually extend the sealed type == | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code php> | ||
+ | sealed interface A permits B {} | ||
+ | |||
+ | class B {} | ||
+ | </ | ||
+ | |||
+ | This code would not produce any errors, as another type ( e.g: `C` ) could exist, in which it inherits from both `B`, and `A`, therefor, an instance of `A&B` could still exist. | ||
+ | |||
+ | == What if the permitted types don't actually extend the sealed type, and are final == | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code php> | ||
+ | sealed interface A permits B {} | ||
+ | |||
+ | final class B {} | ||
+ | </ | ||
+ | |||
+ | In this case, we would end up with an interface ' | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
Line 312: | Line 349: | ||
- | ===== Proposed Voting Choices | + | ===== Vote ===== |
As this is a language change, a 2/3 majority is required. | As this is a language change, a 2/3 majority is required. | ||
- | ===== Patches | + | Voting started on 2022-03-17 |
- | Links to any external patches and tests go here. | + | |
- | If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed. | + | <doodle title=" |
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
- | Make it clear if the patch is intended to be the final patch, or is just a prototype. | + | A Second vote for the preferred syntax choice. |
- | For changes affecting the core language, | + | <doodle title=" |
+ | * `sealed` + `permits` | ||
+ | * `permits` only | ||
+ | * `for` | ||
+ | </ | ||
+ | ===== Patches and Tests ===== | ||
+ | |||
+ | Prototype patch using `for` syntax: https:// | ||
===== References ===== | ===== References ===== | ||
Line 334: | Line 380: | ||
===== Changelog ===== | ===== Changelog ===== | ||
- | - 1.1: added comparison to composite types | + | |
+ | * 1.1: added comparison to composite types. | ||
+ | * 1.2: added FAQ's section. | ||
rfc/sealed_classes.txt · Last modified: 2022/04/01 08:21 by azjezz