rfc:default_ctor
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:default_ctor [2014/11/19 17:03] – stas | rfc:default_ctor [2018/03/01 23:52] (current) – RFC was declined carusogabriel | ||
---|---|---|---|
Line 3: | Line 3: | ||
* Date: 2014-11-05 | * Date: 2014-11-05 | ||
* Author: Stas Malyshev, stas@php.net | * Author: Stas Malyshev, stas@php.net | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | This RFC proposes to introduce the concept of default constructors into PHP. The meaning of it is that whatever is the parent class, child class can always call %%parent:: | + | This RFC proposes to introduce the concept of default constructors into PHP. The meaning of it is that whatever is the parent class, child class can always call %%parent:: |
===== Proposal ===== | ===== Proposal ===== | ||
Line 58: | Line 58: | ||
The call to the %%parent:: | The call to the %%parent:: | ||
- | The call to the parent constructor would be a regular function call, which means it will evaluate its arguments, if provided, and produce all other effects that the function call produceds. However, the call would return immediately without having any other effects. | + | The call to the parent constructor would be a regular function call, which means it will evaluate its arguments, if provided, and produce all other effects that the function call produces. However, the call would return immediately without having any other effects. |
===== Implementation ===== | ===== Implementation ===== | ||
Line 69: | Line 69: | ||
This RFC chooses the second approach, because the first one will result in much larger refactoring of the engine, due to the fact that right now class, interface and trait tables are handled in the same way, but ctor insertion needs to be performed only for classes, but not for others. So introducing it will require changing a lot of code everywhere we create classes or interfaces, to introduce the information needed to separate them. | This RFC chooses the second approach, because the first one will result in much larger refactoring of the engine, due to the fact that right now class, interface and trait tables are handled in the same way, but ctor insertion needs to be performed only for classes, but not for others. So introducing it will require changing a lot of code everywhere we create classes or interfaces, to introduce the information needed to separate them. | ||
- | Also, it would change the actual method table, which will require either substantial changes to all reflection-related functions (to skip the implicitly defined methods) or possible BC breaks where the actual method set of the class is not what the class creator expects. | + | Also, it would change the actual method table, which will require either substantial changes to all reflection-related functions (to skip the implicitly defined methods |
Also, this can lead to more subtle BC breaks. Consider this code: | Also, this can lead to more subtle BC breaks. Consider this code: | ||
Line 83: | Line 83: | ||
Right now, in PHP, the call to bar() is not executed since Foo's ctor does not exist. However, if we change it so that Foo's ctor always exists, the call to bar() would be executed. Granted, this code does not have the best style, but there might be some code in the field, especially after multiple refactoring rounds, and changing how it works still will be a break. | Right now, in PHP, the call to bar() is not executed since Foo's ctor does not exist. However, if we change it so that Foo's ctor always exists, the call to bar() would be executed. Granted, this code does not have the best style, but there might be some code in the field, especially after multiple refactoring rounds, and changing how it works still will be a break. | ||
- | The current implementation only changes how the %%parent:: | + | The current implementation only changes how the %%parent:: |
+ | Also note that only " | ||
===== Other Methods ===== | ===== Other Methods ===== | ||
- | %%__construct%% is not the only method with this usage pattern, %%__destruct%% and %%__clone%% have essentially the same issue. So it can be said that the same arguments outlines above apply to these methods too and consequently the same functionality should be implemented for these methods. | + | %%__construct%% is not the only method with this usage pattern, %%__destruct%% and %%__clone%% have essentially the same issue. So it can be said that the same arguments outlines above apply to these methods too and consequently the same functionality should be implemented for these methods. Thus, this RFC includes the implementation of the same functionality for them too. |
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | No backward incompatible changes, since it is highly | + | No backward incompatible changes, since it is highly |
====== Interactions with __call ====== | ====== Interactions with __call ====== | ||
Line 103: | Line 104: | ||
===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
- | https:// | + | https:// |
+ | ===== Voting ===== | ||
+ | |||
+ | Since this RFC changes the language semantics, the 2/3+1 vote majority is required for it to pass. The vote is a straight Yes/No vote. | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | The vote concludes on the end of the day, PST, January 24th. | ||
===== References ===== | ===== References ===== | ||
rfc/default_ctor.txt · Last modified: 2018/03/01 23:52 by carusogabriel