Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82619
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 209.85.212.176 cause and error)
MIME-Version: 1.0
In-Reply-To: <F79D6CDF-20DD-4E24-B2F4-F12637368242@ajf.me>
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me>
	<CABBJUpf=wKvGY9+xORRv6WVhCb5+LfRZXGYNasHFS=fz_mwaZQ@mail.gmail.com>
	<CABBJUpeceN1uDK870eV2=znC9f3eaxqYCmaEk0ErH2cbFxTNEw@mail.gmail.com>
	<CABBJUpdYnaR2nztPwFUdDAiAneRrAWzGo-36-DA9hqiBjEHXNA@mail.gmail.com>
	<54DAF884.7000508@lerdorf.com>
	<203e611c8e0b03568a868b8d931aec37@mail.gmail.com>
	<F79D6CDF-20DD-4E24-B2F4-F12637368242@ajf.me>
Date: Fri, 13 Feb 2015 17:29:58 +0100
Message-ID: <CAEPJdu=WEs6q1M8dbojev91XGGZ+7H+gqi3ZOGcsfGkAOBXHug@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01419d1c58acb6050efabf30
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: kontakt@beberlei.de (Benjamin Eberlei)

--089e01419d1c58acb6050efabf30
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 11, 2015 at 10:46 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> > On 11 Feb 2015, at 21:30, Zeev Suraski <zeev@zend.com> wrote:
> >
> >> -----Original Message-----
> >> From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
> >> Sent: Wednesday, February 11, 2015 8:37 AM
> >> To: Xinchen Hui; Andrea Faulds
> >> Cc: PHP Internals
> >> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
> >>
> >> On 02/10/2015 07:57 PM, Xinchen Hui wrote:
> >>>> am I wrong?!
> >>> seems I am wrong with this, it's a false alarm...  it can restore
> >> automatically.
> >>
> >> Yeah, declare() doesn't span files so that isn't a problem.
> >>
> >> My worry is still the lack of type coercion for internal calls.
> >
> > There's also some pretty interesting analysis on this proposal - based =
on
> > some real world experimentation - from Benjamin Eberlei
>
> I disagree with some aspects of the blogpost:
>
> > enabling strict mode completly defeats the purpose, because now we are
> forced to convert manually, reimplementing weak type hinting in our own c=
ode
>
> This isn=E2=80=99t true at all. The key difference between explicit conve=
rsions
> and implicit conversions is that they=E2=80=99re, well, *explicit*. You c=
an see
> them, they are blatantly obvious, if you use grep you can find them.
> Implicit conversions, while they can sometimes be great, happen silently
> and automatically - if they screw up, it can be hard to track down where
> the conversion is taking place. With explicit conversions, you=E2=80=99re
> converting once and you know you=E2=80=99ve converted. With implicit conv=
ersions,
> you have no idea where and how often values are being converted.
>
> > We write code with casts already, the scalar type hints patch is not
> necessary for that! Only a superficial level of additional safety is
> gained, one additional check of something we already know is true!
>
> Yet in the previous part he was explaining how existing code doesn=E2=80=
=99t use
> casts and would need them added=E2=80=A6 so therefore, this thing *isn=E2=
=80=99t* already
> known to be true, and the blogpost is self-contradictory.
>
> > strict mode is useless for library developers, because I always have to
> assume weak mode anyways.
>
> I don=E2=80=99t really understand at all=E2=80=A6 either he doesn=E2=80=
=99t understand the
> proposal (which guarantees you get the types you ask for), or it=E2=80=99=
s a
> reference to the claim from the previous paragraph, which I=E2=80=99ve al=
ready
> responded to.
>
> > In a well designed application or library, the developer can already
> trust the types of his variables today, 95% of the time, without even
> having type hints, using carefully designed abstractions (example Symfony
> Forms and Doctrine ORM): No substantial win for her from having strict ty=
pe
> hints.
>
> Yet he was previously explaining how, actually, data coming in from web
> requests isn=E2=80=99t the correct types.
>
> > In a badly designed application, the developer is uncertain about the
> types of variables. Using strict mode in this scenario she needs to start
> casting everywhere just to be sure.
>
> In an application using strict mode everywhere with scalar type hints
> everywhere, you can=E2=80=99t possibly be uncertain about the types of va=
riables.
>
> =E2=80=A6 there=E2=80=99s a lot more in that blog post I could disagree w=
ith, but I won=E2=80=99t
> bother. Benjamin has his reasons for not liking strict mode. That=E2=80=
=99s fine.
> But if PHP adds strict mode, it has zero effect on him.
>

Wait i almost forgot, it *does* have an effect on me, especially around
callback handling:

https://gist.github.com/schmittjoh/778e044deacc6f1fe516

Essentially callbacks are evaluated in the mode they are called in, not in
the one they are defined.

>
> > If you've voted on this RFC or intend to vote - please spend the few
> minutes
> > to read through his blog post.  It does a good job at actually
> illustrating
> > what life would look like if this rubber ends up meeting the road.
>
> Anthony Ferrara also had his own analysis which showed some of the
> problems with weak type hinting, and where strict types can be beneficial=
:
> http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html
>
> I would suggest people read that blog post before voting, as well. It
> points out some real-world examples of where weak typing in PHP can be
> insufficient (div), or even downright dangerous (curlopt).
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e01419d1c58acb6050efabf30--