Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Thu, Jan 4, 2018 at 7:21 PM Rasmus Lerdorf  wrote:

>
> > On Jan 4, 2018, at 13:09, Andreas Hennings  wrote:
> >
> > A system where all variables are type-locked could in fact be faster
> > than a system with dynamically typed variables.
> > Depends on the implementation, of course. I imagine it would be a lot
> > of work to get there.
>
> I think you, and many others, commenting here, should start by looking at
> the engine implementation. Any successful RFC needs to have a strong
> implementation behind it, or at the very least a very detailed description
> of how the implementation would mesh with the existing engine code.
>
> The reason we don’t have typed properties/variables is that it would
> require adding type checks on almost every access to the underlying zval.
> That is a huge perf hit compared to only doing it on method/function egress
> points as we do now.


I’ve been thinking on this during my drive today to a new job and city. I
promise to read over the current implementation before going further, but a
quick question - what if the underlying zval wasn’t a zval but a separate
class specific to the data type but implementing the same interface as
zval? The compiler would choose to use the alternate classes when it
encounters new syntax calling for their use, in effect adding a static
typic layer that augments the existing dynamic typing layer.



>
> -Rasmus
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Rasmus Lerdorf]

> On Jan 4, 2018, at 13:09, Andreas Hennings  wrote:
> 
> A system where all variables are type-locked could in fact be faster
> than a system with dynamically typed variables.
> Depends on the implementation, of course. I imagine it would be a lot
> of work to get there.

I think you, and many others, commenting here, should start by looking at the 
engine implementation. Any successful RFC needs to have a strong implementation 
behind it, or at the very least a very detailed description of how the 
implementation would mesh with the existing engine code.

The reason we don’t have typed properties/variables is that it would require 
adding type checks on almost every access to the underlying zval. That is a 
huge perf hit compared to only doing it on method/function egress points as we 
do now.

-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Andreas Hennings]

On 3 January 2018 at 21:26, Rowan Collins  wrote:
> Hi Michael,
>
> On 02/01/2018 10:35, Michael Morris wrote:
>>
>> I would like to propose a clean way to add some strong typing to PHP in a
>> manner that is almost fully backward compatible (there is a behavior
>> change
>> with PHP 7 type declarations). As I don't have access to the add RFC's to
>> the wiki I'll place this here.
>
>
> Thanks for putting this together. Perhaps unlike Andreas, I think it is good
> to look at typing changes as a unified framework, rather than considering
> "typed properties", "typed variables", etc, as separate concerns. If we
> don't, there is a real risk we'll end up making decisions now that hobble us
> for future changes, or over-complicating things in one area because we're
> not yet ready to make changes in another.

I think the best strategy is to develop a greater vision of where we
want to go, and then identify manageably small steps that move us in
this direction, and that do not create conflicts in the future. This
means we are both right.

I still think the following are good "small steps":
- typed properties with type lock
- typed local variables with type lock
- discussion whether and when parameters should be type-locked in the
function body.

Of course there should be consistency between those steps.

You are right, we also need to consider when these types should be
validated, and/or how the variables would be implemented.
Perhaps we could actually create a system where type-locked variables
use less memory, because they no longer need to store the type of the
variable?
E.g. a type-locked integer would only use the 64 bit or whichever size
we currently use to store the actual number.


> The biggest issue with any proposal, though, is going to be performance. I 
> don't think this is an incidental detail to be dealt with later, it is a 
> fundamental issue with the way type hints in PHP have evolved. PHP is 
> extremely unusual, if not unique, in exclusively enforcing type constraints 
> at runtime. Other languages with "gradual typing" such as Python, Hack, and 
> Dart, use the annotations only in separate static analysers and/or when a 
> runtime debug flag is set (similar to enabling assertions).

A system where all variables are type-locked could in fact be faster
than a system with dynamically typed variables.
Depends on the implementation, of course. I imagine it would be a lot
of work to get there.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 5.6.33 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.33.
This is a security release. Several security bugs were fixed in this
release. All PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.33 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.33

To verify the downloads, you can use the following information:

php-5.6.33.tar.bz2
SHA256 hash:
07f696a9761dcd839e2045c95c3a4d2ffb52c54417477cca9d30a14975b831cc
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJaTCfVAAoJEMK/C8Qzz8izEKwH/AoTrnxvfSFX4jCxRAu2Bxr9
hrjRxTYNMDqe60kfcCMbZsLhkBLc/WEdoDf5D1aydKia0crq8yWOIPFk2L1UXeKW
O2me6iXLwM+xmhbsNT/2oWXLvlM8ZIrjQLSt5Bqfhr/woOj+pRuVel94SbxzwO5v
p6KL7S39NWFbT90Y73Sh6z5XX63FMGVtRC02fzWbgId0Feo2ihFDMVHx3P8z0ZLk
6pvMX8gg77t+rWb8Wca3cSuYRpOCibMQ/Do96Zpg1bfqA7ewD/Ttj8rbC02qARBQ
kGLnJa/0Ch79dRYqVbB2X4Y8hozOVf6yqhCC1CkERLIDAlfwHMvrS/wqPZrgNY0=
=fiFg
-END PGP SIGNATURE-

php-5.6.33.tar.gz
SHA256 hash:
bedfac81cfaa25961812a1aec458c4109411a14991b43a416343ffb830b8da6a
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJaTCfbAAoJEMK/C8Qzz8izxBEIAOvDfffiOwpyy/tp/tIAb08C
XxJYiM6H5ISGkjUVqkmabemoGrz2micTavUJ8qDS8b5zzo4ZY/FCslq3ENTqBhBh
9r5PAcgOKR6tJdoZTdjPt2V8S01h7iJKebKy1xG9j8BtW5V00E27guMnSFWpYGjF
pQYIFgi04BatMCcFV5/Lvv9PECByLQ4TCtFdi43/OfLV6AovIp9xFNRATWys78uL
DcOGG1+zuL87jF85txL3LF5fNVNmb1sPZB6VQqgos37nwLSIVM2j1akeh/kBzztx
BdK4XNLfGjG6xFaxt1zH143hgGWfUWBo9XQnpQg5vrqGbzHhm0DhXHqOdTHHMWM=
=QBu+
-END PGP SIGNATURE-

php-5.6.33.tar.xz
SHA256 hash:
9004995fdf55f111cd9020e8b8aff975df3d8d4191776c601a46988c375f3553
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJaTCfhAAoJEMK/C8Qzz8izviEH/1EZHwfsuQpbeL5xJOKtlkt5
UMxGuPbHMWHrE9sbNtfO0RTUmfhgwDvaceWGmc3B2jPYaZAuTOCNuVNhJptt06JX
BAhE1BR3TvraIpgP7MOM7uRLuN8VL3GX4jGOJJCn4VDNK3BVaJ+/XMCQo4KE8zbW
wf2fTBG7EfDBDEWa9j0HJ6dEqkrKw0SOdcm3RkqZ9CR+E8nRkQ/4CH8d+nylW1im
2W/C5s5vHxmccCjy7VQ1YGIGP59xBwD3bNEVrHuFigLK56e4hLtcJtm17gtrAgkB
nzHdcu+n9BfGD/B78kqiJZOGPe51IrzEi6DXHuiU6QwYAiomTofKPQZos4jcFF8=
=DfMM
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

[PHP-DEV] PHP 7.1.13 and 7.2.1 Available

[Sara Golemon]

I'm happy to announce not one, but two new PHP releases today.
PHP 7.1.13 and 7.2.1 are ready to go at http://php.net/downloads.php

The Windows binaries are available per usual at:
http://windows.php.net/download/

Hash Values and GPG signatures can be found below and at:
7.1.3: https://gist.github.com/sgolemon/72a7ce295c22610228896f37c27e8a36
7.2.1: https://gist.github.com/sgolemon/bb2d82e60052fc5cc2ed0a81eafae4f0

Thank you, and happy testing!
-Sara

php-7.1.13.tar.gz
SHA256 hash: 12fcbf59c9eb9af215ef38815d5da39b9d74549092c34b0dfc31442699740ce9
PGP signature:
-BEGIN PGP SIGNATURE-
iQItBAABCAAXBQJaTEE3EBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXIophAA
1uWs9I04STIGPpEUiS0zE+aULn4ZA77IAloM6Q7cZOZl+MAedokBlyjpzKvgzYm2
mq+vbkEmgGEPQtegkEodSUJfhcZp94ZDEqxeDtYmXZTD0yKhnoVgIhUiDS2rG5Td
+YWBXhEuNLs07I8SoqCNOxe2UHP32IW+yzVzEmGkFbQlspRraiekFCxPTqxQF689
8rwKT/iPVuu/w2tPJCGFgGcS5TfdFJtUyy6N7oFX41OjaagAZYWDy5Fnp4pZ2y/4
Wpi2EdlaWWliwDuBUM1wOXsA1ZCeABetQO4lqasFHes7J41cZxMicluCVYtfKDqS
Ep2mh9TcNjc8kam7fVU1TuSdAydFn5vJ0HIKcvvbblN5qogpb9b7rR/C92XU0gFe
Hjofnt6J5MPAJRy2RdUSwJlvKx+uzR4cg5bx/0zWwBYoVc/GU7e/UsEwiD/INWc2
VS+PeC6BSyFhFPvqy57leXyLCY/s870MnkwbCMKiHhvb5ST9fEu2qKk5GD6ksLeH
QeYEyxapAxajnCNLVAg29S/FmzzSyIRh0dISVzzHCJenB7v0VEPGm10GMnnfwceC
KumedhE818AjYMs6OyezT1JQfaiDm/ZSXkxmf/zTK+nXCTgNQ8MK0RgYiMYqE/mt
8I1MGEeLPclEEjXRQ37ZyRh5c7LXoHvjmCcv7ENsezM=
=eIlS
-END PGP SIGNATURE-

php-7.1.13.tar.bz2
SHA256 hash: 35fda51d2d44600940185fd5818d336a79e77ab3c98e2bd075091f2f91cf98a1
PGP signature:
-BEGIN PGP SIGNATURE-
iQItBAABCAAXBQJaTEE7EBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXK9rw//
axeGHm7IzQ40O/QyXu/CjN3OWou0yZIzqmYlTVHxgWb+xcD+quhlW5K5cFoVK5Qq
Z/siTHZ0iKMy2517iSLliUOgp9owlu5DPBeDsLCtC79NDuQg321iWDfx3F3+Ml1e
xfvTobhDZ9s/q9q0qi+cQQfYHs5AycCidHan4Tavu/90Ur3VEzWuhU5A0wspQSVr
i49+FNci+NPuftC+9SRqJzarB3BOLGfa1s7dJUWfgofhVleuv1ZW8BD+p52RXDel
QTLXfJiXX4BL8YqPcZxbnPEbMVfDDI7OHXZOa6RnWxwTvSgo8Kbww631lcsBA91l
vMvNaca20hfAYGuvbYonbm4fQYroVC/whwBtPM5OXcXIv7wUgZdV86LxOv5snnWA
ds13tZ41i76hDPsfldUYrvJOwOcHeFpPOlhfzaN0B9rQnCvIXHprm96ErvJ824oU
Qzmw27tJ1nNqblPXj+0+G0ULMYruBip7eCWDPsd1VFpzGgDfxGfyZH3vxyhj3sjS
LdWdHZ2/t9AAZFacx3nBIuQJjmOneOcih2myb022O/89FSRoeTlZPWAdwSyQdVNA
WJI2OzyvVeRNcXmeVxP0i+b7fc8RHEtU/xTtTtJGHAYf5RSL17KjRSRaw251W3Iw
R5RlrKUVQ9o5fWAsOQqXeJmEibs9QqdQEuuRuH3e22U=
=o1P6
-END PGP SIGNATURE-

php-7.1.13.tar.xz
SHA256 hash: 1a0b3f2fb61959b57a3ee01793a77ed3f19bde5aa90c43dcacc85ea32f64fc10
PGP signature:
-BEGIN PGP SIGNATURE-
iQItBAABCAAXBQJaTEE7EBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXIvoQ/8
D9l0nn0W8xwe8eTe8B2SUd7TjouVTwcFMawMf0CFav2Lmfc+kqVJrjFUsayw9sfe
fBx5UGKnQ7hhhsxxwG2O07HRloPujtgq2iqa7TqOLIuNMYoWfExsmI1p3Ru+upuf
UdB4RyeGZOJs/dTcE7pMK0UYBOsPlf8uYTp8wn6NvDOSQWfGR7o3kgbGwPHCvmj4
2ZelmAUvejXwAUyygk1jtfBdlDhUeDGFwA4KD6SUQ4FYcXfJ9kWVbKWv0W0HJ0BZ
7LrqGM973nPF0BiFOlW8hFAkkQtnDxvhqdA4uhvlrNinsy9lbyXkHz4VK5Rksr6G
N9pK8S1bwLfRK16EpsZhfH/jzTAkpbCUOV6rJJOJC4sV821/1nadIbzElsfUXFic
drFulalpguF6kX99KJs33pdgWDqfrCgZmSPazgOh/mFOL0/n8lsUKlPnW3rpyi6A
ZQLUOpNF6QvMR7r7SRzfPx+tekL+0w07CrZueRIZpTpBIXF9b6RW2JtysU1SWzHF
GlM6267NtD/2inE6kkAH5LKhfNRwQH5HoqiBoX9XyMTByQ9R255FOYg//dxI5HjO
b0b6d/y09EH0XsocGTNMQ86Cp7svmqfCjWZlu+2BizXfCUpW/8SwpkZNE7aVId33
QnHTVwYyag1Y/y9oCM1Dg+lYU0R0VrXhhpnRBnwJyQI=
=Oj2q
-END PGP SIGNATURE-



php-7.2.1.tar.gz
SHA256 hash: 8ecb2950571054a00687ccbd023874a4a075ccd1e2ec3dc00fc25ef589a77dba
PGP signature:
-BEGIN PGP SIGNATURE-
iQItBAABCAAXBQJaTA1sEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXL2OhAA
zjopx6m30pqDJYod2L+4bef9Ww2VBKfS9um8O7uTSl65Ook4GybUt/5sYbnW1RCi
96Bb1Ir83mty7JNphrG1OEZMkF8NBNLLr0/Jkdl6wkIVzrBmgwt5XgjwiZVVNFHq
uiiXVr+khMSSW2l5Oo4GBvmR+wPNAbUtxKv4TAt8dBY3La8dcZiScyG1/DP25INC
P1jfoWe8X4vOaeVYlSgDEk5KkFKuJyWr4SqHV7egvroZHCmh3vabjMUOu1Mn4/qh
QXWM4cimz1XTbjlaXfJSr8TnNpbTEXsO0X1C9pn/S07CjYkfP+6qDzT8PHtovpGY
xtWzHYlJHbkkyHI3XVCi9nM9EtBt1H7i32gWYvX239jZLZRdoe91O35yNLXvSD4f
uoHoar0Z6JmtUcWC8LPCu38qjox3zPCwg2ZiWj3D75x3NSbpl9HtntSHXcg528Zy
MfbpiwZOys9sVxVCkaAxnG5qZXVF6IpGd1MXY0U5t0yBNqZIk0Kv17HcD1XwCYk+
BLqd6A9L+SMgUosHsTKW2Puh2DZVHpJOEepgx3xApKp/WHBeZ5HGMSjC5fxBYv+/
4q5pKlBIzFKuEjwlFwBuJk9jGWp3zV3XjYGQmbhEmHTilgBaLtvGgyT1b9c1GOqr
CC18tosBoc3mFX8pPVNIySAHH2cR3fbceP/gXvy3Bc0=
=4axu
-END PGP SIGNATURE-

php-7.2.1.tar.bz2
SHA256 hash: fe06793f268a4dd29cbc5f4ef415f01e786877152b02221ad7d18dbb6864eb79
PGP signature:
-BEGIN PGP SIGNATURE-
iQItBAABCAAXBQJaTA11EBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXLk2w//
cVr0MS3CpvD9aKBilR9MUaLFnpnFKIyHCU9RJxcIOqiArAGrZXyJ4fMLBZ37JrwP
EKUnfo777cJQwXjdvxA5V66uvPSV6Mgeshtr/4WoAbsaiVx5XUWXgATikdCcx7AR
bw0g9IXkCUugueTO90ENBSwIY2V1JIhSBWaGm3ddJan7Qox/ATMCR3mghViXOl6E
W1xDq4ZL8tYVil/+bJ6MgaDPZcDwF0EoE/2CStLUYCYriCUlSEB5XUV7vNDTgfg8
Y2VCib5TgJQ/7j0i/bI4FjPetPvVtQdy6yR+qdzm8Doytg0K0BLlHTul8BiYMtgf
5eEHDK8ico0Bbqbx7nOdYR1tDse9kM3tUmbepvYG0zq87TPh5u6/lfDjtYsX4Z+h
Aw9oRguDmbZSyJs/nS81MK+hUIBdIn+uQ8y301Gh4ktdG3nfR/1192Yavrm/yl0k
a8WLze6WHHxTefC4kbUsTqWaW5PLGeHBEJAKdmsUXj+dOQgXHIKQMxmakJ0a2UDb
ptoFLyzme/5zKzvqEhZHjn0fexbtJSmfk/6RKhX/gJwz2MNTPVvq9eKyBXN118QW

[PHP-DEV] PHP 7.0.27 is available

[Anatol Belski]

Hi,

The PHP development team announces the immediate availability of PHP 7.0.27.
This is a security release. Several security bugs were fixed in this release.

All PHP 7.0 users are encouraged to upgrade to this version.

This release is the last to contain the active maintenance patches. The further 
releases
of the 7.0 branch will be issued on demand and contain only critical security 
relevant
bug fixes. The security support is provided till December 3rd 2018. It is a 
good time to
plan the migration to an actively supported PHP 7 version, 7.1 or 7.2 at this 
time.
For more details, consult:
http://php.net/supported-versions.php

For source downloads of PHP 7.0.27 please visit our downloads page:
http://www.php.net/downloads.php

Windows binaries can be found on http://windows.php.net/download/

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-7.php#7.0.27

Regards,
Anatol Belski and Ferenc Kovacs


P.S. Below is the verification information for the downloads

php-7.0.27.tar.bz2
SHA256 hash: 99fa2563bb4c4c1cde9febe87cfe97324227d7b4b8828f2e936e507127394131
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAABAgAGBQJaS0l1AAoJELyqMOqcDVdjAKsH/ju8LE7nQ7ozbDzna9xi641v
bJ8S7dZDpqtPPbENd4fDj7+K74OuKB7hL+aT8iGnuMUaYBULemWOKEcTJU+dJdY9
jvS5Ysw1dwV+gBM4xOw7kAZYDMtU/TGx/8NOEyQjFtiP9FnGYLZZMCUN0JG6Qjn3
4HW2UUJ251KgCvnqaT08GYkos+fEpL86Zg0NHshuoNt5cSn7UlUy5yfuxlzjHlGV
YBaEIQQ1md3IAT7Bp1YaK4Q2GVgQfYMCiAV+ad86k4UD+TQSyA1ZmvtfPVQThDFi
2ge46kbxz7CB8k+rQvpsCajQpu2iMuFzB5EeGUjvzJT3F26ZsHUp/UgjTe7CP8s=
=httW
-END PGP SIGNATURE-


php-7.0.27.tar.gz
SHA256 hash: 809c0181e970dd17c6a6cabbf64518e719c7253e7490f8e1279bc1e1fbdf7996
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAABAgAGBQJaS0l4AAoJELyqMOqcDVdjLsAIALimZRYqtcrmJc/JG5nbkJ91
vu0bInwayS7T/AIfTgLDdT4RHKDik30Z193RVXXojG5fDE6Dc/aL9hoatZ7F6z2X
NLsA+71uUAgkuGX60gF19Sjig2w1EyEx+paj2y43DvzjQMU2a47F0MmaO7f+3zKT
OL5zWdOArb8bm5duYFImMZhkHCJ6ozzndNNW9CJZZzjAx2dZOqFK64t/5XCNe6bL
0CFaCq1dAoyj8uVsFK2AK7kv0sVKQau8yliEwOxnaX2iF6snGgEpcoiOII+8IRFZ
Efm92OzkhIkS1FRQi3CdSNwU7+o2NjNuSclk5nEVOiFXYhauXEXwZIBakwL8Ez4=
=pK5q
-END PGP SIGNATURE-


php-7.0.27.tar.xz
SHA256 hash: 4b2bc823e806dbf7b62fe0b92b0d14b0c6e03f88c3fc5d96278416c54ce11f6c
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAABAgAGBQJaS0l7AAoJELyqMOqcDVdj8AgH/1PKuNrxnCuyKuxi3PNA8S60
4EMnB2d1RYDqeQFkDsbs+mHF4X1Df5F2E0AQXRMshipEn21PtqgvSQ8FmDdFetrw
+G+htCxI/imA+ITNjGVypuCsBR8Z5CQFQ7W1tNgRBaMhJlqsHJyuSLQcuwHvwb9o
KEzbyD1e6VdHhalHw9MUg6YiVCO9QyCVpGB7D/oGH7xI4xYg+il8emSVsGPCEC/o
WRadXwZvEawqftbZ3y5A1Ov2gZ3SXmKQ57vZbsogAeCGOpV0kOiEEqtbrl2yTelh
V6cM1ZQFyVkBp/TAmfXqYcfreA4dZXha29DZMuBdVWzd6wqKkfm8XnkL01gitIc=
=LNeW
-END PGP SIGNATURE-



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Personal Home Page

[Thomas Hruska]

On 1/2/2018 5:54 AM, Lester Caine wrote:

At what point did 'Personal Home Page' become 'Professional Home Page'?

I sat down this morning to look at the sites that are still on the
'TODO' list with a view to just what I can do with them and if the
clients could do anything to help. The short answer is NO since the
reason I'm nursing many of them is because the error messages when
trying to run them on a later version of PHP does require some level of
professional programming skill. Gone are the days one could simply
'google' a quick fix! In many cases the sites simply give white screen
and a 'personal' user has little chance to recover so one moves the site
back to an older version of PHP until one can get around to looking at
it ...

So how to proceed? Well I think it is time I cut many of these clients
loose, and to be honest they will be better off with one of the 'free'
hosting options that flood the market these days. They just reload the
content and change things like contact forms to what the hosting is
offering. That will get rid of all the .ASP sites that I've never had
time to convert to PHP, and all the static sites that probably never
needed PHP in the first place. The problem is I'm not the sort of person
who can say 'sod off' but I think I am going to have to a lot less
helpful in future :( But even saying no takes time ...

A lot of the recent threads have been on a basis of 'Then you should
learn to program properly'. But PHP had a very short learning curve
years ago and one did not need to be a 'programmer' to write and
maintain simple dynamic sites? Admittedly today the infrastructure we
have to live with is a hell of a lot more complex than it was, but PHP
used to isolate that. Today there seems to be so many different
frameworks all of which compete with one another, and nothing that
supports the 'personal' user at all? Even MySQL code is being messed up
with MariaDB variations and very basic hosting gets problematic. Even
the claim that 'one does not have to use this new code' neatly sidesteps
the simple fact that the key libraries we rely on bring that very new
code into the framework and then one has to understand why things that
worked last update no longer work. That is not necessarily because 'the
code was faulty previously' and more likely because of the
'improvements' to the library. Checking everything for every update of
browser, OS, PHP version, library change, urgent security fix, all take
time many of us don't have.

Back in 1982 I earned a Masters Degree in 'Digital System', a fore
runner to 'Computer Science'. I've tried to keep up with the new bits,
but much of what is being loaded into PHP today has no use to a
'Personal Home Page' user and should be in a separate library of tools
for the professional under the hood users ... YES a personal user needs
to know that they have a variable that stores a number, but they also
need to know the limits on the number perhaps depending on other
variables, simply requiring that an unbounded string is restrained to an
'int' thing is of little practical use to many users ... they still need
the validation library whether they understand 'strict typing' or not.


The above was very difficult to comprehend due to poor sentence 
construction.  It seems like you are attempting to address code 
complexity and technical debt issues present in every code base, 
regardless of language.


Around the start of every year, I evaluate where I want to be at the end 
of the year.  I can only guess that you are doing something similar 
right now, which might explain the source of your e-mail to internals.


I recommend reading about Norris Numbers:

https://www.teamten.com/lawrence/writings/norris-numbers.html

Every programmer has a Norris Number rating as does every organization. 
All programmers start at 2 Norris (i.e. the number of lines of 
application code that they are comfortable with writing and maintaining 
by themselves).  Eventually they graduate to 20, 200, 2000, and so on as 
their skills improve.  I have much more to say on the topic of Norris 
Numbers but I'll leave it at this.


Languages similarly grow.  Whether or not that growth is appropriate is 
up to the language designers.  There are generally two schools of 
thought:  Keep a language as-is so that new programmers (low Norris) 
have a chance to learn most of the language OR add new features that 
experts of a language (high Norris) can take advantage of.  Great 
languages find a way to strike a balance between those options by making 
reasonable compromises while minimizing technical debt accrued in the 
language's design.  IMO, over the last decade, PHP has generally done 
"okay" in this area while C++ has done "poorly".


As to wanting direction for your business operations, one of the 
StackExchange sites might be a better place to ask.  The simple solution 
is to provide a deadline:  "Thank you for your business over the years. 
We are in the process of retiring our 

Re: [PHP-DEV][RFC][DISCUSSION] Strong Typing Syntax

[Michał Brzuchalski]

2018-01-04 3:37 GMT+01:00 Michael Morris :

> Second Draft based on the feedback upstream.
>
> Target version: PHP 8.
>
> This is a proposal to strengthen the dynamic type checking of PHP during
> development.
>
> Note - this is not a proposal to change PHP to a statically typed language
> or to remove PHP's current loose typing rules. PHP is a weakly typed
> language for a reason, and will remain so subsequent to this RFC. This RFC
> is concerned with providing tools to make controlling variable types
> stronger when the programmer deems this necessary.
>
>
>
> VARIABLE DECLARATION
>
> PHP currently has no keyword to initialize a variable - it is simply
> created when it is first referenced. The engine infers the appropriate type
> for the variable, and this may be later cast to other types depending on
> the context of the code. Objects can have magic functions to carry out this
> casting such as __toString.
>
> It is sometimes useful to explicitly state a variable's type. One case is
> when the engine might incorrectly infer the type. For example "073117" is a
> valid octal integer but also a date string in mmddyy format, so a
> comparison with another date string in the same format could be... amusing.
> While there is a string comparison function, that functions presence is
> borne of the fact that we can't reliably compare "073117" with say,
> "010216" because of the int casting possibility.
>
> Since the scalar types have already been reserved as keywords they can be
> used to declare variables in a manner not unlike C or Java.
>
> int $a = 073117;
>
> The var keyword is still around from PHP 4 days but is going unused.  In
> JavaScript var is used to formally declare a variable though it isn't
> required (It remains important because without it JavaScript will search
> the scope chain of the current closure all the way to the top scope. If it
> doesn't find the reference it only then creates one. This can lead to huge
> headaches so the creation of variables without using var is strongly
> discouraged in JavaScript).
>
> Since the keyword is available, let's make use of it.
>
> var $a = "123";
>
> What I propose this will do is formally declare $a, infer it's type, then
> LOCK the type from casting. If further assignments are made to the variable
> the quantity being assigned will be cast to type desired if possible,
> otherwise a type error will be raised.
>
> var string $a = $_POST['date'];
>
> This syntax allows the programmer to choose the type rather than allowing
> the engine to infer it. Here $_POST['date'] might be provided in date
> string that might be confused for an octal int.
>
> This magical casting is suggested because it follows the spirit of PHP, but
> it may not be strict enough. For those the type can be explicitly declared
> without using the var keyword as follows.
>
> int $a = 4;
>
> In this event a type error will occur on any attempt to assign a value to
> $a that isn't an int.
>
> The variable can still be re-declared in both cases so.
>
> var $a = 4;
> string $a = "Hello";
>
> The var keyword can be combined with the new keyword to lock an object
> variable so it doesn't accidentally change
>
> var $a = new SomeClass();
>
> As noted above a deliberate redeclare can still change the type of $a.
>
>
If $a is declared with an int type shouldn't it be enought to simply freeze
it's type
to int? var keyword was used in PHP4 and PHP5 and I suppose no one uses it
in PHP7 anymore, why not deprecate it? IMO it shoudl be burned

If all variable declarations with type would lock it's type then var
keyword would be
useless am I right?


>
>
> ARRAYS
> All members of an array can be cast to one type using this syntax
>
> var string array $a = [ 'Mary', 'had', 'a', 'little', 'lamb' ];
> int array $b = [1,2,3,5];
>
>
Personally I really don't like proposed syntax, there are some work in
progress
in subject of generics and IMO that should be the right way to declare
generic types.


> Or members can be individually cast
>
> var $a = [ var 'Todd', var 'Alex' ];
> $b = [string 'id' => int 1, 'name' => string 'Chad'];
>
> Again, following rules similar to the above.  The main reason for doing
> this is to insure smooth interaction with the pack and splat operators.
>
> function foo (var string array $a = ...);
>
>
Here again why not just lock it's type here if we expect $a to be int. I
assume if someone
declares it as array or string he did it with some purpose.


> And speaking of functions, that's the next section.
>
>
>
> FUNCTION DECLARATION
>
> Variables are also declared as arguments to functions.  I propose using the
> var keyword to lock the resulting variable and perform a cast if possible.
>
> function foo( var string $a, var $b ) {}
>
> Note that using var without explicitly calling type will be legal if rarely
> used for consistency reasons. Also, someone might have a use for an
> argument who's type could be anything, but won't change after it is
> received.