Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91489
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.122 cause and error)
Reply-To: internals@lists.php.net
References: <1F.91.55238.41F10D65@pb1.pair.com>
 <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
 <CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com>
 <FA.10.10408.29514D65@pb1.pair.com> <56D42CD3.6020602@gmail.com>
 <DB.E1.07778.3D165D65@pb1.pair.com> <56D57DF4.8000906@gmail.com>
 <56D5D2AD.6070805@gmail.com> <56D5DDA6.4080607@fleshgrinder.com>
 <40.73.36499.548B6D65@pb1.pair.com> <56D6BBD0.5010505@gmail.com>
 <56D73386.3000903@fleshgrinder.com> <86.68.21983.A2508D65@pb1.pair.com>
 <56D86C00.6000904@fleshgrinder.com> <56D870FC.80205@gmail.com>
To: internals@lists.php.net
Message-ID: <56D8752A.9040307@fleshgrinder.com>
Date: Thu, 3 Mar 2016 18:32:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56D870FC.80205@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="xQk8roqmwF2LbmDFha6448NJQInC4O1GM"
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: php@fleshgrinder.com (Fleshgrinder)

--xQk8roqmwF2LbmDFha6448NJQInC4O1GM
Content-Type: multipart/mixed; boundary="RQUXQ38q10vSxdSaKfmvabm7LwQ2hjtbw"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <56D8752A.9040307@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
References: <1F.91.55238.41F10D65@pb1.pair.com>
 <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
 <CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com>
 <FA.10.10408.29514D65@pb1.pair.com> <56D42CD3.6020602@gmail.com>
 <DB.E1.07778.3D165D65@pb1.pair.com> <56D57DF4.8000906@gmail.com>
 <56D5D2AD.6070805@gmail.com> <56D5DDA6.4080607@fleshgrinder.com>
 <40.73.36499.548B6D65@pb1.pair.com> <56D6BBD0.5010505@gmail.com>
 <56D73386.3000903@fleshgrinder.com> <86.68.21983.A2508D65@pb1.pair.com>
 <56D86C00.6000904@fleshgrinder.com> <56D870FC.80205@gmail.com>
In-Reply-To: <56D870FC.80205@gmail.com>

--RQUXQ38q10vSxdSaKfmvabm7LwQ2hjtbw
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 3/3/2016 6:14 PM, Rowan Collins wrote:
> Having no plans to use something doesn't make it a problem. There still=

> needs to be some actual problem you are solving by removing it.

I think in general that it would be helpful to have clear guidelines
regarding such topics. They would make deprecation discussions in
general simpler.

On 3/3/2016 6:14 PM, Rowan Collins wrote:
> Let's not make generalisations about people's motives here. I am
> expressing *my* reasoning for being against removal; others may have
> other reasons, and you can discuss those with them.

:)

> My point was that bulk changing "var" to "public" is a
> counter-productive change. It removes the information "this property's
> visibility has not been reviewed", without actually adding any value.

I understood your motivation and it is a very valid as well as honorable
one.

> This leaves us with a small gain (clearer to new users that the correct=

> keyword is "public"), and two small costs (the need to run a script ove=
r
> all existing code to change "var" to "public", and the loss of
> opportunity to manually review all instances of "var"); I'm not willing=

> to quantify those, but the balance doesn't feel in favour of change to =
me.
>=20
> If there were some way of preventing users writing var in *new* code, I=

> would be all for it - there is no advantage to doing so, and it adds no=

> value to have two ways of writing "public". But there is no way for the=

> engine to distinguish new code from "legacy" code which already contain=
s
> the keyword. If someone can come up with a clean mechanism for doing
> that (and in particular, for new code to say "I'm including this legacy=

> library which I will replace with modern code shortly, don't bother
> telling me how many deprecated features it uses"), then I would be very=

> interested.

I always thought that E_STRICT is exactly that. I mean, an upgrade path
like ...

# do nothing in PHP 5 (as is),
# emit E_STRICT in PHP 7,
# emit E_DEPRECATED in PHP 8,
# remove in PHP 9

=2E.. would be fine with me too and go back to what I said initially: a
clear policy. Note that it would add several more years to the upgrade
path (6 years?).

Of course it is bad that people simply suppress those errors but that is
something that is completely out of control for us. People could easily
log them into a separate log as well during development and disable them
in production ...

Such a practice could also be easily applied to the RFC that proposes to
clean up many old inconsistent functions ...

# do nothing in PHP 7,
# emit E_STRICT in PHP 8,
# emit E_DEPRECATED in PHP 9,
# remove in PHP 10.

That results in around 9 years of time to adopt.

https://wiki.php.net/rfc/consistent_function_names

The biggest problem is when languages change to fast and for no real
benefit as we have seen it with many other languages and it almost
happened with PHP 6 (although the intention was good there).

--=20
Richard "Fleshgrinder" Fussenegger


--RQUXQ38q10vSxdSaKfmvabm7LwQ2hjtbw--

--xQk8roqmwF2LbmDFha6448NJQInC4O1GM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW2HUvAAoJEOKkKcqFPVVrKeIP/0iZf0VyQnU3tNwfQNMUsu7q
V5qrm8y+jk8lK3k9ZZbKl3fo+CKale8dhd6muqW91umaEZPF+uKenj3OzXYCZ2Sg
SfXTVq5CTWQ48+yr+Wx5/TVzev1PtP/oLtR+/Bniq8sQslFfBR8AFz/Tl/x9tULm
r6KMRWLpmixwr2euGFR5Y5bSe0as5FUDaFVaAYJX5kjwl0mn/nxztGb/Wqjf+GWv
l0eCJ4Cw37syOznt6FPn335TwPOKjOFt/99IV06MJpdKqEginxtuljmMG1J7ORAc
LXN8b0F90xf0hn4cZeAOI6r71zelUms4jhXFK25xj7MIKkKbQhkr/hDsLZAR+Rih
onJ/mwxhE/5RZcNbdGQa88JFVQM9JRD4vCNqkcKA9iDJi3dxzq+VtcTg/Fu0bB1C
KUQAsY7HWOPGhj5XileGJoDFUpuUHRcuYQcvYN9oL/7oUXsLwWr/w4az4C2MnUwx
FytEco2zT4+2PSkCOoFvNTIGN9OVk4F/4eWZjUp1gbPnZqTF32tjlszfu0861ckV
QFyrwJxhlRedZH1TTD9LfkdLgIkgwvT7fdWBhzhBo0OqGMv8vdWIuMcRlYWaEY9D
1iqNYH/toyNCCX9NUtYs5v9j9qUN6TDWORCJ341v42XgrYY5N+MDvwWcy+ARJHjY
xLM8QBJLPHcjaUbjxab0
=EVNj
-----END PGP SIGNATURE-----

--xQk8roqmwF2LbmDFha6448NJQInC4O1GM--