Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121709
MIME-Version: 1.0
References: <2b4591c1-f999-49b5-8061-67db816aa0da@gmail.com>
In-Reply-To: <2b4591c1-f999-49b5-8061-67db816aa0da@gmail.com>
Date: Fri, 17 Nov 2023 14:01:13 -0300
Message-ID: <CADK1yX+fM4gaao859eOEUSGej+jdVGSUkezJQ_XTga0yG1L8gQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a2f23d060a5c171b"
Subject: Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed" properties
From: deleugyn@gmail.com (Deleu)

--000000000000a2f23d060a5c171b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 16, 2023 at 5:41=E2=80=AFPM Rowan Tommins <rowan.collins@gmail.=
com>
wrote:

> Hi all,
>
> I have finally written up an RFC I have been considering for some time:
> Harmonise "untyped" and "typed" properties
>
> RFC URL: https://wiki.php.net/rfc/mixed_vs_untyped_properties
>
>
> Currently, changing a property declaration from "private $foo" to
> "private mixed $foo" changes its behaviour in significant ways, even
> though no actual type checks are added. This RFC seeks to remove those
> differences, by extending the "uninitialized" state currently reserved
> for typed properties to cover all declared properties:
>
> * Properties without an initial value will be "uninitialized", not "null"
> * Calling "unset" on a declared property will make it "uninitialized",
> rather than the current complex behaviour
>
>
> There are a handful of open questions still in the RFC, but I wanted to
> present an initial draft to start the discussion, because the current
> behaviour is quite hard to explain in a short e-mail.
>
> Please let me know your thoughts.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I have mixed feelings about this. Reading just the email gives me the
impression of an unimaginable BC Break with the potential of holding back
PHP upgrades A LOT. But reading the RFC, it is pretty clear that what we
have now is a consequence of entropy and what is being proposed is to
explicitly make a plan with all existing cases in mind. The fix for the BC
is something trivial: null was implicit but now will require explicitness.
The behavior which makes existing code work seems easy to get in place.
However, the amount of code that would need this and the fact that Rector
is not used by every PHP Developer is something that makes this a big deal.

The thing I like the most about the proposal is making a sensible choice to
cover the scenarios that are intertwined. Considering what has been said
about opt-in making things harder with no desired mass adoption, perhaps
what could be done instead is an easy-way-out (opt-out). An attribute that
can be added to the class and have it automatically default untyped
uninitialized properties to null. This allows the original proposal to
stand and allow for a wide adoption while still giving a way-out for
computer systems written 30~15 years ago that are still running and still
being slowly refactored / rewritten.

One thing to make it explicitly clear about my suggestion, I don't want or
intend to have an attribute that keeps the current engine as-is + develop
the engine with the new behavior because in my mind that could mean
multiple areas of the engine and it could be quite complex to handle. My
proposal is more about an ad-hoc self-contained Annotation that simply goes
through the class and automatically set everything to null before the
engine does its thing. In a way, it could still be a BC-break no matter
what - 2 different behaviors of the language, but I'm thinking that such
attribute could make things behave as-is 99% of the time and allow legacy
systems to still breathe.

--=20
Marco Deleu

--000000000000a2f23d060a5c171b--