Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82017
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.42 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <CADajX4Dza_bu6AsiSEiWYCWgf9-4QJbUfKdmPP4NZnJ3iUBSMg@mail.gmail.com>
Date: Thu, 5 Feb 2015 22:13:44 -0800
Cc: Andrea Faulds <ajf@ajf.me>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D199E145-6DAE-4F17-96BC-CC6EA635AC29@zend.com>
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me> <CADajX4Dza_bu6AsiSEiWYCWgf9-4QJbUfKdmPP4NZnJ3iUBSMg@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: andi@zend.com (Andi Gutmans)

+1

> On Feb 5, 2015, at 5:23 PM, Adam Harvey <aharvey@php.net> wrote:
>=20
> On 6 February 2015 at 04:14, Andrea Faulds <ajf@ajf.me> wrote:
>> At long last, I=E2=80=99m going to put the RFC to a vote. It=E2=80=99s =
been long enough - I don=E2=80=99t think there needs to be, or will be, =
much further discussion.
>=20
> True, and I probably won't respond to any replies to this because we
> don't need more noise, but I do want to explain my -1 vote. This is
> long and rambling. I apologise. I've posted a formatted version of
> this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case
> it's easier to read.
>=20
> In no particular order, my issues with this RFC:
>=20
> ## The declare switch
>=20
> Adding the cognitive overhead for each file for developers to have to
> remember whether they have to cast a value before passing it to a
> function or if PHP will automagically do that for them is a bad thing.
> Of course, in a small, well compartmentalised file, or a single
> developer code base, it wouldn't be a problem. Unfortunately, a lot of
> PHP projects aren't that tidy. (Probably most of them, in fact.)
>=20
> I also disagree with the comparisons that have been drawn on Internals
> between `declare(strict_types=3D1)`, `use strict`, and `from =
__future__
> import foo` statements. They're not the same thing at all:
>=20
> * `use strict` is ultimately about code quality =E2=80=94 am I doing =
something dumb?
> * `from __future__ import foo` is ultimately about features =E2=80=94 =
yes, I
> want to opt-in for the new shiny.
> * `declare(strict_types=3D1)` isn't either of those, although it might
> superficially appear so =E2=80=94 what it's really about is "I reject =
your
> philosophy and substitute my own" in terms of typing.
>=20
> There are structural decisions we can and should let our users make. I
> believe this isn't one of them: allowing users to fundamentally change
> the typing semantics of a language on a module-by-module level is, in
> my opinion, insanity. Languages have to be opinionated about this sort
> of issue: if they weren't, there'd only be one programming language
> and it would have 800 switches to configure before you could write a
> line of code. This sort of decision is the whole point of designing a
> language: abdicating it by providing a switch is effectively us
> shrugging and saying "sure, whatever, we don't care, so now we'll make
> you care".
>=20
> ## Strong typing
>=20
> This ties into the previous point: for scalars, PHP has never been a
> strongly typed language. I was once on the train of strict typing
> being universally better =E2=80=94 if you know that you always have an
> integer, you never have to worry about a bad conversion, right? And,
> if I was designing a language from scratch, I'd probably still feel
> that way.
>=20
> That language wouldn't be PHP, though. PHP is unapologetically weakly
> typed from top to bottom. Designing a feature to break that would be
> bad enough. Designing a feature to optionally break that is insidious.
> If you care about whether the zval IS_STRING, you can check that
> today. Encouraging our users to care goes against the entire
> philosophy of the language.
>=20
> To be clear: yes, we have problems in our type conversion matrix. The
> fact that `"21 Jump Street" =3D=3D 21` is an issue (particularly =
because
> it's silent), and we should be talking about that. But strong typing
> is not the solution.
>=20
> ## Caller versus callee
>=20
> Making the caller responsible for choosing the type behaviour is a
> clever hack. (No pun intended, Facebookers.) I find the idea
> intriguing from an academic perspective. Unfortunately, as with the
> above point, this isn't consistent with PHP as a language that's
> existed for 20 years and had type hinting in its current form for over
> 10 years. If we accept this, then we only widen the gap between scalar
> values and array/object ones: for one set of type declarations, the
> behaviour is determined entirely by the callee, and for another, it's
> determined by both the callee (via the type hint) and the caller
> (whether it will be converted or not).
>=20
> ## So what do we do for 7.0?
>=20
> =46rom where I sit, we had a good solution: it was the 0.1 version of
> this RFC. It behaved like PHP should behave, respected PHP's long
> standing scalar type handling and conversion rules, but most
> importantly, it solved the **actual** problem scalar type hints are
> supposed to solve in the simplest possible way:
>=20
>    Can I guarantee that my function that expects an integer will
> really get an integer?
>=20
> I don't think that adding complexity on top of that helps anyone in
> the long run. Yes, we get to tick some extra boxes =E2=80=94 "we =
support
> strong typing", "we support weak typing", "we put the user in control"
> =E2=80=94 but at the cost of having a language that not only supports, =
but
> advertises multiple, inconsistent behaviours, requires users to be
> aware of conversion minutiae that they shouldn't have to be mindful
> of, and doesn't do anything to solve the actual problem above.
>=20
> Adam
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20