Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118772
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
In-Reply-To: <a2c2c00a-9bad-77e7-0bb6-9c91f1cc250b@gmail.com>
Date: Fri, 7 Oct 2022 00:36:28 +0300
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <4CBBFC17-2B9A-4FD8-BCBC-98DD49F55C78@gmail.com>
References: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
 <CAAwFBqoG0wjRxVXC8FvBHv5uCJYVYNJWLEGTnAX7DiYUO3rpVQ@mail.gmail.com>
 <CABigaAU+eR718cEHUmwxNdBuMyQSwKkhnR2SfMo1otiMwrq+jg@mail.gmail.com>
 <EB5DD38F-6A46-4D07-B011-00179E91724C@cschneid.com>
 <CAEsg9X0DAh+Y45LUdG=aFOo4cWvmBU2Vfg48YcnsQkdh1grEdg@mail.gmail.com>
 <CALKiJKqcwkMW8Dw9Htxzt=Swkz08uY5XNEOrLq2qEsyTrJczTA@mail.gmail.com>
 <C45353A1-0666-4857-AC9F-99DA0BB90031@gmail.com>
 <1aa20877-3365-0ace-25d2-1cb1be8f3bcc@gmail.com>
 <55686BD4-4C67-4A4F-8BE4-BDF0149296FB@gmail.com>
 <a2c2c00a-9bad-77e7-0bb6-9c91f1cc250b@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Experimental features
From: autaut03@gmail.com (Alex Wells)



> On 6 Oct 2022, at 23:12, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 06/10/2022 17:41, Alex Wells wrote:
>> For example, Kotlin has recently introduced a new feature - unsigned =
integer types.
>=20
>=20
> I'm still struggling to understand what I, as a user, would do about =
this.
>=20
> If I start coding an application that relies on these new types, is =
there a chance that they'll be removed completely, and I have to rewrite =
it all? Is there a chance that every minor version I upgrade might =
introduce subtle changes in the behaviour of my code? Or is there just a =
chance that someone will decide the bikeshed's the wrong colour and I =
have to regex replace all my "123u" to say "u123" instead?
>=20
>=20
> Regards,
>=20
> --=20
> Rowan Tommins
> [IMSoP]
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20

Yes to all. There's a chance for anything to happen with an experimental =
feature any time.=20

This of course doesn't mean it has to happen; actually, it barely ever =
happens. It's not like Kotlin ships features without thinking them =
through - it's just that they have that fallback to introduce a breaking =
change without any additional hassles (like deprecations or keeping a =
backwards-compatibility promise) if they want it.

Allowing breaking changes in patch releases in Kotlin does sound =
reasonable - at the very least most breaking changes will get caught on =
compilation stage.=20

This won't happen with PHP, so we're likely better off still limiting =
any breaking changes to minor/major releases. Yet we're still winning in =
a sense that there won't be any deprecations needed (which not only =
saves a lot of time, but also simplifies the process a lot) and will =
have a safe window to change the API altogether when problems arise.=20

You as a user act as an alpha-tester of language's feature, with all the =
related pros and cons. You get access to all the newest and shiniest, =
but you have to always keep track of PHP's changelog (much more than =
"regular" users) and be prepared to act upon breaking changes (again, =
possibly a lot more than regular users).=