Hi Andreas,
On 18/06/2020 17:02, Andreas Hennings wrote:
I am ok with restricting the use of "return *;" inside a constructor.
But I don't like allowing the ": void" declaration.
The way I look at it, constructors are mostly declared like a normal
method - they use the keyword "function";
Hey Andreas,
> Another example would be the "public" access specifier, which can be
omitted and the method will still be public.
>
> There is a major difference though:
>
> If you look at a method without "public", or a parameter without "mixed",
there is a chance that the developer actually
On Thu, Jun 18, 2020, at 3:49 PM, Andreas Hennings wrote:
> On the other hand, for a constructor the ": void" is just stating the
> obvious.
> Even if you see a constructor without ": void", you still know that this is
> not meant to return anything.
> Either because it is generally agreed to be
On Thu, 18 Jun 2020 at 22:29, Benas IML wrote:
> Hey Andreas,
>
> It seems that you actually haven't read my reply carefully enough.
>
> > But this distinction would only apply in PHP 8. And the only difference
> here
> is whether returning a value is just deprecated or fully illegal.
> > In PHP
Hey Andreas,
It seems that you actually haven't read my reply carefully enough.
> But this distinction would only apply in PHP 8. And the only difference
here
is whether returning a value is just deprecated or fully illegal.
> In PHP 9, constructors with ": void" would be the same as without ":
On Thu, 18 Jun 2020 at 18:33, Benas IML wrote:
> Hey Andreas,
>
> That is incorrect. Adding an explicit `: void` does change behavior since
> only then the check (whether something is being returned) is enforced. This
> allows PHP 8 projects to take advantage of this enforcement while being
>
Hey Bob,
Your examples (regarding constructors/destructors) do make sense since you
are using these methods for what they should be used: initialization and
freeing resources. But, this is off-topic to the RFC.
This RFC only proposes to enforce no-return rule on
constructors/destructors. And
Hey Alexandru,
Your email was marked as spam for me, thus this is a late response,
sorry about that!
Nikita analyzed top 2,000 Composer packages and found that 95 of them will
have a BC break. As a solution, to minimize the amount of BC breaks, I'm
proposing to have a deprecation warning in PHP
Hey,
> Am 18.06.2020 um 17:18 schrieb Benas IML :
>
> Hey Bob,
>
> Magic methods are **never** supposed to be called directly (even more if that
> method is a constructor or a destructor). If that's not the case, it's just
> plain bad code. But by enforcing these rules, we make sure that less
Hey Andreas,
That is incorrect. Adding an explicit `: void` does change behavior since
only then the check (whether something is being returned) is enforced. This
allows PHP 8 projects to take advantage of this enforcement while being
respective to older codebases.
And well, the explicit `:
Hi
The RFC introduces what I call a "meaningless choice", by making something
possible that is currently illegal, but which does not change behavior.
https://3v4l.org/daeEm
It forces organisations, frameworks or the php-fig group to introduce yet
another coding convention to decide whether or
Hey Bob,
Magic methods are **never** supposed to be called directly (even more if
that method is a constructor or a destructor). If that's not the case, it's
just plain bad code. But by enforcing these rules, we make sure that less
of that (bad code) is written and as a result, we make PHP code
> Am 17.06.2020 um 01:10 schrieb Benas IML :
>
> Hey internals,
>
> This is a completely refined, follow-up RFC to my original RFC. Based on the
> feedback I have received, this PR implements full validation and implicitly
> enforces `void` rules on constructors/destructors while also allowing
Hi Benas,
This looks good to me.
Can you do a research on top 1k-2k most used composer packages and verify
how small the BC break it is?
Also, a suggestion on how to fix the BC issue if it exists could be
mentioned I guess.
Thank you,
Aled
On Wed, Jun 17, 2020, 02:11 Benas IML wrote:
> Hey
Hey internals,
This is a completely refined, follow-up RFC to my original RFC. Based on the
feedback I have received, this PR implements full validation and implicitly
enforces `void` rules on constructors/destructors while also allowing to
declare an **optional** explicit `void` return type.
15 matches
Mail list logo
