Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
References: <CAL=_i_ndnBUEHUcNxPJxxkhZ70jM4xE-xkjuftWpHHNSKMchOA@mail.gmail.com>
 <BY2PR0201MB1784884D794E3FF56E08D124BF500@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAFMT4Noi+=r=oEkSHkkdYy7UJ0VCw-CH-iP8LfJOrovCMm7-bg@mail.gmail.com>
 <2f0b0366-de16-25ef-f5ca-a03fb7d6f38b@zend.com>
 <575AE7EE.7050208@garfieldtech.com>
 <3246c813-95b4-a120-f1e1-9763edba0af8@gmail.com>
Message-ID: <575AF8CF.2090101@garfieldtech.com>
Date: Fri, 10 Jun 2016 12:28:47 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <3246c813-95b4-a120-f1e1-9763edba0af8@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: larry@garfieldtech.com (Larry Garfield)

On 06/10/2016 11:57 AM, Rowan Collins wrote:
> On 10/06/2016 17:16, Larry Garfield wrote:
>> That seems like a worthwhile trade-off for a <1% performance difference
>> in a real-world application.
>
> The problem is that the performance hit is felt even for code that 
> doesn't "opt in" to this feature. For an application that makes no use 
> of the feature, it is all cost and no benefit.
>
> I think PHP is at a cross-roads, and (if you'll forgive the stretched 
> analogy) at risk of going off-road and getting stuck in the mud.
>
> Option 1 is that the language remains inherently loose-typed, with a 
> few entirely optional features to provide type safety in specific 
> cases. If this is the aim, then the optional features should be as 
> unobtrusive as possible for the "default" loose-typed approach. Any 
> performance hit on untyped properties is a big deal under this 
> interpretation.
>
> Option 2 is that the language embraces "gradual typing" as a core 
> tenet of the language, with loose typing considered a "fallback". If 
> this is the aim, then there should be a coherent roadmap of what the 
> type system is going to look like. In this case, performance issues 
> might be considered an inevitable cost of improving the language; they 
> might also be reduced as the Engine is adapted to implement the roadmap.
>
> Option 1 seems more appealing, because it is easier to get agreement 
> for, but if we keep piling on the special cases, we're going to end up 
> with the worst of both worlds. I see the technical problems with 
> creating a reference to a typed property as a sign of this: we are 
> creating more of the frustrating inconsistencies that PHP is infamous 
> for, because we're trying to have our cake and eat it.
>
> For the record, I'm not entirely sure which way I want the language to 
> go, but I think it's a decision that needs to be made, and soon.
>
> Regards,

This is a very accurate and well-stated assessment.  I agree with the 
possible paths.

 From the code I see in the wild, it feels like the gradually/mostly 
typed camp has already won in terms of production code.  Most of the PHP 
Rennaissance-era systems (the stuff that came out in the last 5-6 years 
or so) is class-heavy and as type safe as PHP has allowed, most of the 
time.  The exceptions are the highly functional bits, where the language 
doesn't offer as much support as it does for class-family typing.

There's almost certainly some projecting going on here as I'm a 
mostly-typed fan myself, but my sense is that the PHP user-space 
community has already decided they want a robust typing system they can 
use in most (but not all) cases.  The engine should embrace that and 
catch up, with a well thought-out approach to typing.  If it takes a bit 
longer to get certain features as a result of that attention to a 
coherent roadmap, I am happy to make that trade-off.

--Larry Garfield