Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83346
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nHMqCbhz2c0X6otad-B4-TY5OgRwRX-y=Buu=BTwz9cbQ@mail.gmail.com>
References: <20150220170854.308596800F2@frontend2.nyi.internal>
	<CAAyV7nFuk+zuS3nMjf79ou0Rr9Qu20jEcE5=wFYiASV5NnYcQg@mail.gmail.com>
	<54E77D2E.60407@lerdorf.com>
	<CAAyV7nHMqCbhz2c0X6otad-B4-TY5OgRwRX-y=Buu=BTwz9cbQ@mail.gmail.com>
Date: Fri, 20 Feb 2015 14:07:23 -0500
Message-ID: <CAAyV7nGYtW1X+skCPX3i4xc4LyTyAz51i8WChA87i=QpU4oyYg@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Larry Garfield <larry@garfieldtech.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: ircmaxell@gmail.com (Anthony Ferrara)

Point of clarification: it exists in the RFC already:
https://wiki.php.net/rfc/scalar_type_hints_v5#internal_functions_should_opt-in_to_typing

On Fri, Feb 20, 2015 at 2:06 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> Rasmus,
>
>> To be perfectly transparent here though, you should mention that your
>> proposed RFC goes well beyond the strict typing that is in Hack because
>> in Hack the internal API is largely untyped while your proposal is to
>> default the entire internal API to strict types in strict mode. Also, in
>> Hack there is a distinction between the off-line hh_client type-checker
>> and the runtime.
>
> In addition to what Josh said, I want to make one point here. This
> distinction is what lead me to push out 0.5 instead of where 0.4 was
> going. Let me explain:
>
> Let's say we don't type internal functions and release 7.1 with the
> rest of the dual mode type system.
>
> Then we're bound to never strictly type internal functions *unless* we
> introduce a NEW declare setting (declare(strict_types=2) or
> declare(internal_strict_types=1) or whatever). Which is a bit out
> there considering people already are testy about this one.
>
> So that practically means if we don't allow strict now, we can never
> tighten it again.
>
> However, if we do allow typed now, then we can expand and loosen in
> the future. If an API is found to be overly strict, it can be loosened
> (using a union type for example). We have the ability to loosen over
> time, but not strengthen.
>
> That's why I chose to apply the same typing to internal functions as
> user-land. To not to would be a major mistake IMHO. So that's why I'm
> moving forward with it. I will add this to discussion points in the
> RFC.
>
>> So when you say, and as I have heard other people say, that people want
>> Hack-like strict typing, you have to be a bit careful about what is
>> meant by that. Even in the cases where the internal API is typed in
>> Hack, it is still not a runtime fatal if they are called with the wrong
>> types. Now whether that is a good thing or not is debatable, of course,
>> my point is simply that if you are going to use Hack adoption as a sign
>> "that people want static typing" you should clearly explain that your
>> approach is quite different from what Hack is doing.
>
> It's not "quite different". It's subtly different in a few details.
> But conceptually it's the same.
>
>> Right, you are doing a gradual transition of an API that wasn't written
>> to be strict. It was written with the assumption that type coercion
>> would take place. If there is a good reason to ease the transition from
>> PHP to Hack there is an even stronger reason to ease the transition from
>> PHP to PHP.
>
> And that's why the current proposal has two modes: weak (coercive) and
> strict (error inducing). The default mode will not change things for
> anyone. Then they can start adding types, and things will just work.
> When they are ready, then they can turn on strict mode, one file at a
> time. Heck, they can run a strict-mode static analyzer on non-strict
> code to see where potential problems will be (assuming the analyzer
> has that mode) so they can fix it before committing to strict types in
> their production app.
>
> If that's not the definition of a "gradual transition", I'm not sure
> what else can be done without fundamentally disallowing the ability to
> strictly type.
>
> Anthony