Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102865
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 64.147.123.21 cause and error)
To: internals@lists.php.net
Date: Mon, 16 Jul 2018 13:17:50 -0500
Message-ID: <1599498.ygS5CM8mOq@vulcan>
In-Reply-To: <CAKOZhE8qwYycAD4EfnxBsF6y-zxUe1n4rtjsgDjVU+BGd8_MHQ@mail.gmail.com>
References: <CAKOZhE8c6L3bTFtne7MPTH0Qf3kfKYYnby71uSUEU75EsfAbgA@mail.gmail.com> <CALKiJKrBbtKnLP0+njH+r7TBO1cPL=D4OtqAd4-8EakiEXKXsQ@mail.gmail.com> <CAKOZhE8qwYycAD4EfnxBsF6y-zxUe1n4rtjsgDjVU+BGd8_MHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart8465036.BZJ66JjviO"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC] Optional typehint check for parameters
From: larry@garfieldtech.com (Larry Garfield)

--nextPart8465036.BZJ66JjviO
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Monday, July 16, 2018 12:23:42 PM CDT Zeljko Mitic wrote:
> On Mon, Jul 16, 2018 at 1:42 PM Rowan Collins <rowan.collins@gmail.com>
> 
> wrote:
> > On 16 July 2018 at 12:06, Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
> >> Basically, you went wrong when you proposed a switch that controlls
> >> language behavior. To add to that - a switch that probably is not
> >> controllable by code that is running.
> > 
> > While I agree with your general principle here, I would like to raise one
> > point in this proposal's favour, which is that PHP's type hints are
> > effectively assertions - if the value is not of the given type at that
> > point, an error is raised. Assertions are always something you turn off in
> > production builds, with a global switch, to the point of compiling the
> > code
> > as though they don't exist, so it's not unreasonable to have a similar
> > switch to disable run-time type checks.
> > 
> > As Nikita points out, this is not true of non-strict scalar hints, so that
> > does raise a complication.
> > 
> > I was going to point to Dart as an example where type checks have been
> > implemented this way, but it seems that version 2 has replaced the
> > "checked
> > mode" with stronger static analysis, and run-time checks are automatically
> > inserted only for cases where the safety can't be inferred.
> > 
> > This might actually be a more promising optimisation for PHP - perhaps
> > OpCache could mark certain code paths as type-safe (or maybe it already
> > does?) As an exaggerated example, this code only really needs to check the
> > value's type once, not four times:
> > 
> > function foo(Bar $bar): Bar {
> > 
> >    return $bar;
> > 
> > }
> > function test(Bar $bar): Bar {
> > 
> >     return foo($bar);
> > 
> > }
> > $something = test($something);
> > 
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> 
> Exactly. Languages like Java and Hack will not compile when sent parameter
> is of wrong type. Once all is OK, generated code will never check that
> value again.
> 
> My suggestion is something between; if during development my code works, I
> don't ever need type check again.

That fails with the potential for dynamic typing.

$class = derive_class_name($_GET['some_input']);

$foo = new $class();

doStuff($foo);

function doStuff(BarInterface $b) { ... }

In PHP you *cannot* know with certainty that all code is type safe at compile 
time.  Removing type checks at runtime will *always* lead to reduced safety 
and at best less useful error messages.  That's just the nature of the 
language.  PHP is not Rust (as cool as that would be).

It sounds like your main argument for why to even bother with this is 
performance.  I think you're greatly over-estimating the performance impact of 
type checking.  I wager if you just cache a few database lookups and you'll 
get a much larger performance win.  For far, far less effort and confusion.

--Larry Garfield
--nextPart8465036.BZJ66JjviO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAltM4U4ACgkQ4MMKwDFx
YXcWCAgA62rB/4mPzgtWMPlU8qu96VjK+b+uc9ZPN7SwCgTw74mvKeLNI2/ljfK/
vWvfuc1lMeMl1WRAW5cVOaLgzr/oN68SeEj+4197JhDfung3iA7KqtoDu3NFB8AT
Jgjhi0/i2Nq2Yzr48bn3Z8uHRKqRfzfy1JKwahXfnccKHs3HfFW1PN84ItHEeoSB
ELTHV2M60cpmGK7Wf6bEGuGYXemCUcXxJkLMZBGp5asiibjPOZM8a+7LXBg0fmtL
dIO4sDvmbFRLRLS3TWVsoyRcyrULCG9Vf1KJf8AXHIuxn3oYxE6dwWgllM4LmHjD
BK2513zLSYgmsqZ3Ea81qA/kvWPdtg==
=HRAU
-----END PGP SIGNATURE-----

--nextPart8465036.BZJ66JjviO--