Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102183
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.67 as permitted sender)
To: internals@lists.php.net
References: <0d108361-f5fa-fe76-b6ad-66e23bfa88f5@loot.at>
Message-ID: <3c36b189-108d-bce7-bea0-7a3d6a432607@gmail.com>
Date: Tue, 5 Jun 2018 23:17:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <0d108361-f5fa-fe76-b6ad-66e23bfa88f5@loot.at>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Better types without runtime checking
From: rowan.collins@gmail.com (Rowan Collins)

On 05/06/2018 08:22, Rudolph Gottesheim wrote:
> There's always a lot of talk about types in the PHP community. 
> Specifically, many developers want property types, generics, function 
> signature types, union and intersection types, and more. Those talks 
> (and RFCs) always end with the same result: "We can't do it because 
> performance issues."
>
> Has there ever been a discussion about adding some of those features 
> syntactically, but ignoring them during runtime? At least until 
> someone finds a performant way to check them at runtime. That way we 
> could have advanced type checking in our editors at least.


Hi,

I believe this is part of the original aim of Hack-Lang: the additional 
type features of that language are not part of the run-time, but checked 
by a static analysis tool offline. A number of languages have similar 
setups - Python and Dart both have the types as offline and/or 
development-mode-only features. Indeed, PHP seems to have gone a very 
unusual route in having a dynamic language with type constraints which 
are effectively always-on assertions.

One of the problems with moving PHP to this offline-checking model is 
that people will expect new type constraints to work like existing ones, 
so may be caught out by them not being checked at run-time. Worse, 
static checks may not be able to detect certain violations; I don't know 
much about Hack's model, but I understand it includes both different 
levels of strictness, and restrictions on dynamic language features - 
things like references, "variable variables", and non-object callables.

I do think it's an interesting question to think about though.

Regards,

-- 
Rowan Collins
[IMSoP]