Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
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>
Message-ID: <3246c813-95b4-a120-f1e1-9763edba0af8@gmail.com>
Date: Fri, 10 Jun 2016 17:57:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <575AE7EE.7050208@garfieldtech.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: rowan.collins@gmail.com (Rowan Collins)

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,
-- 
Rowan Collins
[IMSoP]