Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84980
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXa6P-euEB_h2q1w9wb=Ms6N0DRSe3eDp0rwJx98cqz6sQ@mail.gmail.com>
References: <CAAyV7nFAE07s+o8xW6fYwAu2-goo3riWuuWSTZn4hTo5O58HrA@mail.gmail.com>
	<CAGa2bXZrmQuzCTQ=E8gkGU-N2wV459PfL2VCdmeu_+JQD17LEQ@mail.gmail.com>
	<CAEZPtU7_vEpF=pLQfcF6Y9n-TU4K5D-zxHiSD-bw65S4zsS-ag@mail.gmail.com>
	<CAGa2bXa6P-euEB_h2q1w9wb=Ms6N0DRSe3eDp0rwJx98cqz6sQ@mail.gmail.com>
Date: Mon, 16 Mar 2015 14:31:44 +1100
Message-ID: <CAEZPtU7NWZnSvaSXPreH=AHKMrSGZ6ePz3W0TQ1BNF0MB=sTFg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: PHP internals <internals@lists.php.net>, Anthony Ferrara <ircmaxell@gmail.com>
Content-Type: multipart/alternative; boundary=001a114005424c299e05115f7d96
Subject: Re: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date Change
From: pierre.php@gmail.com (Pierre Joye)

--001a114005424c299e05115f7d96
Content-Type: text/plain; charset=UTF-8

On Mar 16, 2015 1:17 PM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:
>
> Hi Pierre,
>
> On Mon, Mar 16, 2015 at 10:48 AM, Pierre Joye <pierre.php@gmail.com>
wrote:
>>
>> > Coercive type for general developers and strict type for library
developers
>> > will
>> > eliminate more type related bugs, more natural to average PHP users.
IMHO.
>>
>> And change casting rules, open a pandora box. And even worst, it is a
>> zero compromise RFC. Same as before, no need to discuss that any
>> longer.
>
>
> "The same way before" is going to cause problems, or hide problems at
least.
> As Zeev's patch revealed, people do mistakes and the patch helps to find
them.
>
> "The same as before" will just hide these hard to find bugs.

I am against changing how PHP behaves with casting and co, as it does for
years.

This is extremely dangerous.

>>
>>
>> > It's natural that we have different point of views, but we can easily
>> > understand/guess
>> > the consequence of the RFC. Weak mode is simply too weak to be useful.
>> > Strict mode will hide type bugs by errorless casts.
>>
>> Show me examples when something not in strict mode behave differently
>> and it will be fixed. But saying that is per se wrong and double
>> standard in regard of voting. Or why did you vote in favor of other
>> RFCs which obviously had or still have bugs?
>
>
> This code is an example that I posted in other thread.
>
> e.g.
> <?php
> function check_num_range(int $num) { if ($num < 0 || $num > 100)
trigger_error('Invalid range'); }
> // Somewhere far from function definition.
> $num = $GET['num'];
> // Somewhere far from $num definition.
> check_num_range($num); // Trying to check validity, int and range.
> echo 'You have '.$num. ' now <br />'; // But $num could have any string.
>                                                             //
"check_num_range((int)$num)" wouldn't help also.
> ?>
>
> Simple cast hides bugs, not eliminates type bugs.
> This is just an example and there are many cases that cast hides bugs in
real world codes.
>
>>
>> > I hope both you and Zeev work together to satisfy most needs because
>> > hiding bugs are not good thing to do.
>>
>> It does but I do not claim that there are no bug, every code has bugs
>> and they should be fixed.
>
>
> I'm not saying the proposed patch has bugs, but I'm saying it hides
"users' code bugs".
>
> Hiding hard to find bugs does not make much sense while there is the
proposal that finds it.
> What I'm trying to say is "Why don't we collaborate?". Let users fix bugs
at first, then
> introduce more strict type checks if it's needed. Coercive type and
strict type can co-exist
> together well, but weak type and strict type cannot.

This example is out of the scope of this rfc. As I said many times, you
want to make php more friendly and let users write better code, that's a
good thing. However changing by default how php behaves for decades is a no
go for me. It will create more issues than it solves.

--001a114005424c299e05115f7d96--