Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83345
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54E77D2E.60407@lerdorf.com>
References: <20150220170854.308596800F2@frontend2.nyi.internal>
	<CAAyV7nFuk+zuS3nMjf79ou0Rr9Qu20jEcE5=wFYiASV5NnYcQg@mail.gmail.com>
	<54E77D2E.60407@lerdorf.com>
Date: Fri, 20 Feb 2015 14:06:15 -0500
Message-ID: <CAAyV7nHMqCbhz2c0X6otad-B4-TY5OgRwRX-y=Buu=BTwz9cbQ@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)

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