Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83147
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error)
Message-ID: <54E589F6.9030002@garfieldtech.com>
Date: Thu, 19 Feb 2015 02:00:06 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <011801d04a07$83ab1c00$8b015400$@php.net>	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>	<016f01d04a3a$e9183220$bb489660$@php.net>	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>	<d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>	<CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>	<022801d04ab1$4a0c47d0$de24d770$@php.net>	<1913e09d7f52541901d8574d2080a63f@mail.gmail.com>	<CAAyV7nFD=BQ5dBYiKzhbOKTomKmWvruTnb=R_n9mYB-Lz1P9pg@mail.gmail.com>	<7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com>	<CAPhkiZxpYbaPN1370_HFTVnBA=Jg-rU8DrB2P+2dmRcJfGWPtw@mail.gmail.com>	<2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com> <CAPhkiZwcD3h42=9eak4uP9n2GBE=v0LVP6Ncq9Oz7L91dJ5y5w@mail.gmail.com> <4cc0c81c7199a452534bb8edcdb19914@mail.gmail.com>
In-Reply-To: <4cc0c81c7199a452534bb8edcdb19914@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: larry@garfieldtech.com (Larry Garfield)

On 02/17/2015 01:30 PM, Zeev Suraski wrote:
>> Yes, I already know that.
>> The difference, and why I keep pointing that out, is that me and many
>> others
>> want strict typing for our own reasons (but still in its entirety instead
>> of as a
>> limited mode) and most of us don't even care if you getting weak typing
>> for
>> your own usage. You can't work towards consensus if your target is to
>> prevent the opposing group of getting what they want. I see both as
>> valuable
>> tools for different jobs and I want to have more tools at my disposal,
>> while
>> you're trying to tell me that I should use only one tool for everything.
> First, it's very important to understand that my target is to prevent the
> opposing group from getting what they want.  I'm really not sadistic :)  My
> reasons were obviously different and worked towards a different goal.  Much
> in the same way that people who vote against an RFC - one of the countless
> that were voted against - don't do that to hurt the ones who support it.
> They do it because they think adding it would bring negative consequences.
> I never believed the 'You don't have to use it' as a silver bullet
> explanation for why it's OK to add features with potentially negative
> implications.
>
> The good news is that I think that in many ways the ideas we're toying with
> right now are better for the strict-type camp, especially if we end up going
> for just one mode, and meet roughly mid-way in terms of strict and weak -
> which I think is doable.  The biggest gripes strict campers had with weak
> mode are gone in this proposal, and unlike v0.3 - that would actually be the
> default (and only) behavior, which is a big gain for the strict campers.
> And the most prominent features of weak typing are kept (dynamic type
> conversion where it makes sense), hopefully making the weak campers happy
> too.
>
>> But you implied that most objections were from people who don't want
>> strict
>> typing in PHP at all. And I disagree with that because it's a speculation,
>> which
>> in turn you are using to favor your weak-hints-only case (hence, twisting
>> it in
>> another direction).
> I didn't imply it now (at least I certainly didn't intend to).  I did
> outright say it a week or two ago, and still believe that's the case but
> reached the conclusion that none of us would gain anything from further
> discussing it.  We won't know unless we start actually polling the people
> who voted and ask, which we're not going to do, and we're obviously not
> going to convince each other.  Much more importantly, it at least *seems* as
> if we have a direction for something that a very wide audience may rally
> behind.  Let's focus on that!
>
> Zeev

At this point, if I could rephrase the "camps" a bit I see two different 
sets of priorities:

1) PHP should do what seems "obviously safe" to do, to make life easiest 
for developers.  That is, it's patently obvious that "32" and 32 are 
equivalent, so don't make developers worry about the distinction because 
to them there isn't one.  This is an entirely reasonable position.

2) PHP would benefit hugely from static analysis tools and compile-time 
type-based optimizations, but those are only possible with code that is 
strongly typed.  Currently such tools do not really exist, but with 
compile-time-knowlable information could be written and even 
incorporated into future versions of PHP without API breaks.  (I think 
Anthony demonstrated earlier examples of function calls no longer being 
slow, for instance, if the type juggling could be removed at compile 
time.)  This is an entirely reasonable position.

Naturally those two positions are mutually exclusive; if the compiler 
has to allow for "32" to be converted to 32 at runtime, it can't 
optimize the opcodes by removing the code that would do that conversion!

I was against the mixed-mode approach before, but I given the above I am 
warming to it.  The trade off here is between DX (in the sense of the 
code "doing what I mean" and not babysitting type information) and 
potential performance and bug-finding benefits. Different places in an 
application may need different trade-offs. In practice, the closer you 
are to an IO action (browser input, database, file, etc.) the more you 
want the "obviously safe" behavior; once you pass one layer of specified 
typing you can be pretty confident that strict checks will "just work" 
from there on out.

In essence, opt-in-strict becomes an opt-in "compiler, be pedantic so 
you can make my code faster" flag.  More carrot than stick, since people 
can control when they opt-in to fancier compiler optimizations at the 
cost of some DX, but only in some cases.

I started this email planning to ask Anthony how flexible strict 
checking could get without losing the benefits of it, but I think I've 
just convinced myself the answer is "not very".  Which then leaves only 
the question of internal functions that Rasmus raised, which... it looks 
like is discussed in later emails so I will try to catch up on those. :-)

--Larry Garfield