Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92603
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.87 cause and error)
Reply-To: internals@lists.php.net
References: <5717D70E.5010706@lsces.co.uk>
 <CAFp73XvfuRJG-ncJXcB0cApBiM72F-Mi+kAxm7A=bvCuo2NnTA@mail.gmail.com>
 <5717E02C.9030505@gmail.com>
 <CAFp73XtSE8KP5h90_yf_nG=K0heEnyywDi-YZ01S8GC9g3SNTg@mail.gmail.com>
 <5717EEBD.80303@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>,
 "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>,
 Lester Caine <lester@lsces.co.uk>
Cc: internals <internals@lists.php.net>
Message-ID: <571925D6.40605@fleshgrinder.com>
Date: Thu, 21 Apr 2016 21:11:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5717EEBD.80303@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="Mjkw7o7Qi0thQvairaUeRW9lvsjCS6Hiw"
Subject: Re: [PHP-DEV] Quick sanity check ...
From: php@fleshgrinder.com (Fleshgrinder)

--Mjkw7o7Qi0thQvairaUeRW9lvsjCS6Hiw
Content-Type: multipart/mixed; boundary="jbla3BXe8B5nljblXXqbptL4ScTqEt910"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Stanislav Malyshev <smalyshev@gmail.com>,
 "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>,
 Lester Caine <lester@lsces.co.uk>
Cc: internals <internals@lists.php.net>
Message-ID: <571925D6.40605@fleshgrinder.com>
Subject: Re: [PHP-DEV] Quick sanity check ...
References: <5717D70E.5010706@lsces.co.uk>
 <CAFp73XvfuRJG-ncJXcB0cApBiM72F-Mi+kAxm7A=bvCuo2NnTA@mail.gmail.com>
 <5717E02C.9030505@gmail.com>
 <CAFp73XtSE8KP5h90_yf_nG=K0heEnyywDi-YZ01S8GC9g3SNTg@mail.gmail.com>
 <5717EEBD.80303@gmail.com>
In-Reply-To: <5717EEBD.80303@gmail.com>

--jbla3BXe8B5nljblXXqbptL4ScTqEt910
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 4/20/2016 11:03 PM, Stanislav Malyshev wrote:
> No of course not. The specific instance of error you had *this time* ma=
y
> be solved. The problem won't be. You still have to deal with:
> - How this object is initialized? How you ensure it *is* initialized an=
d
> that initialization is correct (0 is perfectly valid int)?
> - How this object is unserialized and what if unserialized data has
> non-integer or 0 or __wakeup has a bug?
> - What if some code just writes 0 into $olderThan - you declared it as
> public so anybody could mess with it?
> - What if some code mixes signed and unsigned and you get negative
> number instead of positive?
> - What if this code runs on 32-bit but receives 64-bit value and
> truncates it?
>=20
> And so on, and so forth, I probably missed more possibilities than I
> mentioned. Declaring a type does not magically free one from correct
> design and testing, and typed programs have bugs as much as non-typed
> ones (maybe slightly different ones). Actually, one of the harms relyin=
g
> on it would be the same problem safe_mode had - it's full of holes, it'=
s
> not safe and it creates wrong expectations. If you just write "int" and=

> expect your problems to magically go away - you're in for big and bad
> surprises.
>=20

While I agree with Stanislav and the others that a stricter type system
would not have prevented the bug. However, a stricter type system helps
to limit the amount of tests one has to perform and that is often a good
thing. That does not mean that dynamic type systems are shit. Actually
the opposite is the case, it is the same situation with paradigms.

What I love about PHP is that we have a lot under one hood:
multi-paradigm as well as loose and strict types. This allows one to
choose the best tool for the current job.

Relying on your language for a bit of safety as asked of it cannot be
compared to `safe_mode` where magic happens in the background. When one
declares and `int` than it should be an `int`. Of course that also means
that one should know what an `int` is and how to validate it according
to the current business rules.

That being said, isn't Lester's goal to validate scalar strings all the
time anyways? I mean, at least `mysqlnd` transforms all data from the DB
automatically to the proper scalar types for optimal performance in your
program. But if one keeps scalar strings everywhere and leaves proper
type coercion to PHP, I mean, why not. It is definitely doable and
strict types are definitely not necessary if done properly.

The big difference I see is that Lester is working on his code for
himself (or for a customer) and does not have to design APIs for
hundreds of other developers. PHP is used in the way it was initially
designed, as a glue language. I repeat myself but I cannot see the need
for strict types here.

If you are developing APIs that are going to be (ab)used by hundreds of
other developers in ways you would never have foreseen things change.
One wants to ensure that the API is as self-explanatory as possible and
as easy to use as possible. This includes (to get back to one of your
examples) that objects that should not be serialized are not
serializable (`private function __sleep()`) and not deserializable
(`private function __wakeup()`) nor cloenable if necessary. This
includes self-explanatory required types, sane default values, and
appropriate visibility of things.

PhpDoc is the classical tool for us here and Stanislav wrote in another
thread that this is the tool of choice. I completely disagree with this
because PhpDoc might be nice and already features more complicated types
(e.g. unions), however, it is also lacking many features as the
development of the PSR-5 shows. Another problem is that documentation is
not kept in sync and it is extremely hard to teach people how important
proper documentation is. Believe me, I know. You might say now that
those programmers are bad, well, yes, maybe. But that is what you get
when you are working in huge teams; ask Google.

In the end it is about better APIs for me as I explained in many other
messages and I stay true to that. :)

--=20
Richard "Fleshgrinder" Fussenegger


--jbla3BXe8B5nljblXXqbptL4ScTqEt910--

--Mjkw7o7Qi0thQvairaUeRW9lvsjCS6Hiw
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

iQIcBAEBCAAGBQJXGSXbAAoJEOKkKcqFPVVrYesP/2Px9wa7c0ivsORggTQ9XEQ0
EEyizw0mCmhuJn2joKGcC3qO4G2uvxMy6G8rjBaXe7PWtCKVUFqe7TyaMPC9oOt9
6h0NWiaiqJbQ1sIewU+W1ljs7ouOPQqtBkXXhI7OFJqpiOKxO5KEoS45T597NIzl
ZBGjsh93tpwPiGk6KAU+awM1AwvQrWmr81OnsfHBE5f3otffIAnqhuBYx9ZFhOfl
0IhL4p+20hnlf9gHFknCDMoem/bB8/rGwnll8HkHLXMy+vWoAbIkv6+G5r1fJE5e
dj6tmB3w9ChMhWX1kmcpikA/tBqhjUo29yFDpGaydtFl4een8dTUDuZ00VKykKJ2
OlMsCD602ee+D0/PPlndPsrmRVtWKpYXYoSogx9ZAZqFvuu0LHNljRgBw/MQHJ2z
LRyWTV/Pi5McfYfQTfIK8s+Vtbt/PGc1t3ArB5H4Ms8C9V2KhiafqCfzCrtpiTd4
BHXujuihwBcqpsD0atYs8KnHXTHi0W+/a931ydWAoX2J4ssK7e9kdNCL0zVs59+L
ZojUOIGyOrV9Eokz+GmPsZDEoFz2INrReTAd8UIzG8BHS/GvYr78o1+RXo+NMnTI
RdTUgYD4rnSZbEn0MMFJhQz7pUqb5BSnVqQgtqwEOFxGVjCJku3B8XPJI09KkiBp
PBhaLA8XYQzpZGsJu66B
=Qtdl
-----END PGP SIGNATURE-----

--Mjkw7o7Qi0thQvairaUeRW9lvsjCS6Hiw--