Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <93453174-E6A8-47C6-8AB6-A08858A7FC05@zend.com>
References: <CACwt+JdHCYYVMbuuAZ73N_sfOkQHJ7_EkOtPWtqJcNW7Xgjn3w@mail.gmail.com>
	<EE83CD8A-BAFA-43AC-8CD0-5F123BF96299@ajf.me>
	<93453174-E6A8-47C6-8AB6-A08858A7FC05@zend.com>
Date: Fri, 13 Feb 2015 09:43:58 -0500
Message-ID: <CAAyV7nH0BVvoq0XpGAX=ve2j9RwgUvti+DvR0c7v2BiALg4XWg@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Andrea Faulds <ajf@ajf.me>, Patrick ALLAERT <patrickallaert@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: ircmaxell@gmail.com (Anthony Ferrara)

Zeev,

On Fri, Feb 13, 2015 at 6:34 AM, Zeev Suraski <zeev@zend.com> wrote:
>
>> On 13 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2015, at 13:13, Andrea Faulds <ajf@=
ajf.me> wrote:
>>
>> Hi,
>>
>>> On 13 Feb 2015, at 09:37, Patrick ALLAERT <patrickallaert@php.net> wrot=
e:
>>>
>>> Voted "no" because of the reasons already mentioned by a bunch of other=
s here.
>>>
>>> Weak type hint as presented earlier: +1 (and very good job Andrea about=
 that!).
>>> declare(strict_types=3D1): -1, not only about the syntax, but also abou=
t the mixed mode it introduces.
>>>
>>> I'm pretty confident that this RFC will "pass" with just above 2/3 of m=
ajority while it could reach much more.
>>>
>>> I am pretty sure that if this RFC doesn't include a strict type mode _t=
he way it is proposed_ (or even, not at all, as part of another related RFC=
), it would have some "no" converted to "yes" and would have a wider adopti=
on, which is for sure a better option than relying on a voting mechanism wh=
ich still is a supporting tool, we're not politicians after all :)
>>
>> It wouldn=E2=80=99t have wider adoption. Excluding a large portion of th=
e PHP community (which favours strict types) and giving them something whic=
h doesn=E2=80=99t work for their use cases (weak types) is not going to win=
 any fans.
>
> Any fans?  Really?
>
> How about we put it to a test instead of guessing the outcome?
>

We have long operated as a Do-ocracy in that the RFC author has final
say over what goes into their proposal. You are definitely free to ask
and make suggestions (and share opinions), but ultimately it's up to
the author. Andrea, as the author of this RFC, has apparently decided
that it isn't going to happen in this proposal at this time. Please
respect that, even if you don't agree.

With that said, there's nothing stopping you from putting up your time
to create a competing proposal and patch. If you really believe that
weak types are the better way forward, why not codify that? If only
one of the RFCs passes, then you have your answer. If both pass, we
can simply have another vote to choose which to move forward with.
Competition is healthy for the community.

You also said earlier in the thread that you don't agree with the
points that I made on my blog post
(http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html). Can you
share what you don't agree with (in the comments or this thread)?
Rasmus posted some issues, most of which I consider details in this
proposal (declare() and lack of handling the int->float conversion
case) and I replied to them (I think they are handleable). If you have
other disagreement, why not share?

I would especially would like a response to the point that I made
where I showed 3 examples where weak hints of any type would cause
subtle and hard-to-find bugs; one of which was a high-level security
risk.

One final side-point: In my work on Recki-CT, I learned very early on
that casts are quite expensive. When compiling mandel() from
Zend/bench.php, the implicit casts that were happening on $w2, $x and
a few other vars (which were ints) to floats for the computation added
approximately 10% to the runtime of the function. The casts in mandel2
accounted for 20% of the runtime. Let me say that again: the
int->float conversion in the loops accounted for between 10% and 20%
of the function call. And that's not a dynamic cast (a branch based on
type), it's a single `fild` instruction. Having the ability to
statically know that a cast will never be needed can result in
significantly faster (and easier) native code generation...

Thanks

Anthony