Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82504
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 209.85.212.179 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAEPJdu=bHXpoKKc0_8c9rYEizR6CZ6rgaX1ms_g8dggQp=eOdA@mail.gmail.com>
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>
	<CAEPJdu=bHXpoKKc0_8c9rYEizR6CZ6rgaX1ms_g8dggQp=eOdA@mail.gmail.com>
Date: Thu, 12 Feb 2015 01:03:43 +0100
Message-ID: <CAEPJdu=RtZniG=psCchZeGqwWn_k8=1SwC+5dtFDgThrgy4PBg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc8f9e686cdd050ed8daeb
Subject: Fwd: [PHP-DEV] [VOTE] Scalar Type Hints
From: kontakt@beberlei.de (Benjamin Eberlei)

--047d7bdc8f9e686cdd050ed8daeb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Forarding again, was rejected by the list because of spammy links :(

---------- Forwarded message ----------
From: Benjamin Eberlei <kontakt@beberlei.de>
Date: Thu, Feb 12, 2015 at 12:59 AM
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
To: Andrea Faulds <ajf@ajf.me>
Cc: Zeev Suraski <zeev@zend.com>, Rasmus Lerdorf <rasmus@lerdorf.com>, PHP
Internals <internals@lists.php.net>




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.
>

I agree with the benefits of strict typing and how they are explicit. I
even like programming in strict languages a lot.

But "the default way" to achieve this is in PHP is to add casts, and they
are done "with the weak rules":
strict_func((int)$string); avoids the purpose of strict typing. And that
will probably be the most used way to get strict type compatibility.
Yes, i am probably using it wrong here, but features are not always used
the right way, most of the time they are not.

It got mentoined to me several times that a fix would actually be to have
$request->getInteger('status'); - i will add that to the post later. This
will actually improve the code, but as i mentoined in my post, someone with
a good abstraction for type juggling is already there today.


> > 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.
>

You got me there, but the code i showed doesnt actually "need" strict or
weak types. I use casting in PHP liberaly, as probably many others as well.
If i think I need it, I use it.

>
> > 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.
>

I understand the proposal. As a library author i would use type hints to
help my users make the right input values, recieve the right return values.
But except when I have highly critical code that requires the right types
at all steps, but most of the time inside my library weak type hints would
a.) not step me in the way so much b.) still work out correctly all the
time.

>
> > 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.
>

Well that example didn't show Symfony Forms nor Doctrine. I could show them
in the blog post, but since they cast all the request + db already, there
wouldn't be much to show. As the blog post says, this kind of code already
provides a lot of trust even without any kind of type hints.


>
> > 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.
>

 Yes, thats the benefit of the proposal, it has o effect on my code, as
long as there is no outside pressure on me or my team to write strict mode
only code.


> > 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.
>

@Zeev: I don't like being used, singling out only my blog post because it
proves your opinion, where clearly there were other posts in favour of
strict mode typing, for exampl e ircmaxell his. You are not doing your
opinion a good service imho, by being so obviously political about this
issue.


> 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
>
>

--047d7bdc8f9e686cdd050ed8daeb--