[RFC][Status] Scalar Type Declarations Voting Date Change

Dennis Birkholz

11 years ago

Hi Anthony,

Am 15.03.2015 um 22:33 schrieb Anthony Ferrara:

> Therefore, I am closing votes on this RFC effective tomorrow, March 16th.

could you announce the (UTC) time you close the vote? That is something
most votes miss here...

Greets
Dennis

Anthony Ferrara

11 years ago

Dennis,

On Sun, Mar 15, 2015 at 5:39 PM, Dennis Birkholz <dennis@birkholz.biz> wrote:

> Hi Anthony,
>
> Am 15.03.2015 um 22:33 schrieb Anthony Ferrara:
>> Therefore, I am closing votes on this RFC effective tomorrow, March 16th.
>
> could you announce the (UTC) time you close the vote? That is something
> most votes miss here...

That's a good point. I'll close it at 21:00 UTC tomorrow (just under
24 hours from now).

Anthony

Zeev Suraski

11 years ago

> -----Original Message-----
> From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> Sent: Sunday, March 15, 2015 11:34 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date
> Change
>
> However, it has become exceedingly clear to me that this good faith has
> not
> been reciprocated. The understanding that we had when both proposals
> opened has now been violated. Rules have been broken and politics are
> ensuing in an attempt to sabotage this proposal. Rather than working
> together, "unofficial polls", backdoor politics and poor behavior have
> created yet more toxicity.

Anthony,

Stop accusing me of refusing to work together, backdoor politics and poor
behavior:

- Refusing to work together:  I tried to support numerous ways to evaluate
Bob's RFC, all of which were opposed by you or other Dual STH supporters,
for technicalities - valid or not.
- Backdoor politics:  None of that happening, which didn't stop you from
strongly implying there was with your unprecedented low email from earlier
today, suggesting 'irregularities' that weren't there.
- Poor behavior:    "Sneaky", "Abuse", "Political".  Just 3 words that come
to mind that you used against me or others in the last 3 weeks.

Oh yeah, I'm guilty of the unofficial poll.  At least one person that can't
be blamed to be a blind follower of mine thinks there's nothing wrong with
it (twitter.com/SaraMG/status/577225234375417856)

> Rather than drag this vote on end, and rather than be accused of closing
> "when convenient", I am choosing to move up the ending day to put an end
> to the drama.

Talk about changing the rules mid-flight.

Zeev

Rafael Dohms

11 years ago

FWIW, regardless of the politics and finger pointing here.

I think the only sane way to start solving this is what Anthony has
proposed.
Set a *fair* closing date, with plenty time for both sides to react as they
wish
and let the chips fall where they may.

Its not about Zeev or Anthony or anything else. Its about closure and
moving on.
Let's all stop accusing everyone and focus on reading RFCs and voting.

--
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://www.amsterdamphp.nl <http://wwwamsterdamphp.nl>

Pierre Joye

11 years ago

On Mar 16, 2015 8:58 AM, "Zeev Suraski" <zeev@zend.com> wrote:

>
> > -----Original Message-----
> > From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> > Sent: Sunday, March 15, 2015 11:34 PM
> > To: internals@lists.php.net
> > Subject: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date
> > Change
> >
> > However, it has become exceedingly clear to me that this good faith has
> > not
> > been reciprocated. The understanding that we had when both proposals
> > opened has now been violated. Rules have been broken and politics are
> > ensuing in an attempt to sabotage this proposal. Rather than working
> > together, "unofficial polls", backdoor politics and poor behavior have
> > created yet more toxicity.
>
> Anthony,
>
> Stop accusing me of refusing to work together, backdoor politics and poor
> behavior:

I do not talk for myself but this is what you have been done for too long.
Since 7 started and with the 64bit RFC. It has to stop. You did not respect
your promises for the 5.7/7 timeline RFC, going wild alone while we were
supposed to have one covering all cases. I warned you about the dangers of
your proposal, especially the unrealistic short time for features freeze.
You said we have to be strict. And now? We have to be cool?

Yes this is hard word but I have enough of that. We have created the RFC
process to avoid such situations, but it seems it is not enough.

Now you have two choices. You go further down this road and open the
Pandora box by literally kicking out the rfc rules or you accept that your
proposal fails and let php move forward. I strongly suggest you the latter.

In any case, i am not asking you to stop these political move, pressure and
other rather low moves, I tell you to stop them now. Unconditionally, it
went too far and it is now time to stop.

> - Refusing to work together:  I tried to support numerous ways to evaluate
> Bob's RFC, all of which were opposed by you or other Dual STH supporters,
> for technicalities - valid or not.
> - Backdoor politics:  None of that happening, which didn't stop you from
> strongly implying there was with your unprecedented low email from earlier
> today, suggesting 'irregularities' that weren't there.
> - Poor behavior:    "Sneaky", "Abuse", "Political".  Just 3 words that

come

> to mind that you used against me or others in the last 3 weeks.
>
> Oh yeah, I'm guilty of the unofficial poll.  At least one person that

can't

Pierre Joye

11 years ago

On Mar 16, 2015 9:10 AM, "Pierre Joye" <pierre.php@gmail.com> wrote:

>
>
> On Mar 16, 2015 8:58 AM, "Zeev Suraski" <zeev@zend.com> wrote:
> >
> > > -----Original Message-----
> > > From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> > > Sent: Sunday, March 15, 2015 11:34 PM
> > > To: internals@lists.php.net
> > > Subject: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date
> > > Change
> > >
> > > However, it has become exceedingly clear to me that this good faith

has

> > > not
> > > been reciprocated. The understanding that we had when both proposals
> > > opened has now been violated. Rules have been broken and politics are
> > > ensuing in an attempt to sabotage this proposal. Rather than working
> > > together, "unofficial polls", backdoor politics and poor behavior have
> > > created yet more toxicity.
> >
> > Anthony,
> >
> > Stop accusing me of refusing to work together, backdoor politics and

poor

> > behavior:
>
> I do not talk for myself

Should have been: for Anthony or other :)

Not sure how autocorrect managed that :)

but this is what you have been done for too long. Since 7 started and with
the 64bit RFC. It has to stop. You did not respect your promises for the
5.7/7 timeline RFC, going wild alone while we were supposed to have one
covering all cases. I warned you about the dangers of your proposal,
especially the unrealistic short time for features freeze. You said we have
to be strict. And now? We have to be cool?

>
> Yes this is hard word but I have enough of that. We have created the RFC

process to avoid such situations, but it seems it is not enough.

>
> Now you have two choices. You go further down this road and open the

Pandora box by literally kicking out the rfc rules or you accept that your
proposal fails and let php move forward. I strongly suggest you the latter.

>
> In any case, i am not asking you to stop these political move, pressure

and other rather low moves, I tell you to stop them now. Unconditionally,
it went too far and it is now time to stop.

>
> > - Refusing to work together:  I tried to support numerous ways to

evaluate

> > Bob's RFC, all of which were opposed by you or other Dual STH

supporters,

> > for technicalities - valid or not.
> > - Backdoor politics:  None of that happening, which didn't stop you from
> > strongly implying there was with your unprecedented low email from

earlier

> > today, suggesting 'irregularities' that weren't there.
> > - Poor behavior:    "Sneaky", "Abuse", "Political".  Just 3 words that

come

> > to mind that you used against me or others in the last 3 weeks.
> >
> > Oh yeah, I'm guilty of the unofficial poll.  At least one person that

can't

> > be blamed to be a blind follower of mine thinks there's nothing wrong

with

> > it (twitter.com/SaraMG/status/577225234375417856)
> >
> > > Rather than drag this vote on end, and rather than be accused of

closing

> > > "when convenient", I am choosing to move up the ending day to put an

end

Pádraic Brady

11 years ago

On 15 March 2015 at 21:58, Zeev Suraski <zeev@zend.com> wrote:

>> -----Original Message-----
>> From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
>> Sent: Sunday, March 15, 2015 11:34 PM
>> To: internals@lists.php.net
>> Subject: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date
>> Change
>>
>> However, it has become exceedingly clear to me that this good faith has
>> not
>> been reciprocated. The understanding that we had when both proposals
>> opened has now been violated. Rules have been broken and politics are
>> ensuing in an attempt to sabotage this proposal. Rather than working
>> together, "unofficial polls", backdoor politics and poor behavior have
>> created yet more toxicity.
>
> Anthony,
>
> Stop accusing me of refusing to work together, backdoor politics and poor
> behavior:
>
> - Refusing to work together:  I tried to support numerous ways to evaluate
> Bob's RFC, all of which were opposed by you or other Dual STH supporters,
> for technicalities - valid or not.

Those "technicalities" were basic rules and a PHP7 timeline that
everyone was following, until someone invented new "technicalities"
one after the other in an attempt to get past the original
"technicalities". The attempt has not even succeeded which means we
can have a bit of comfort that they'll continue to be upheld.

I'm sorry, but regardless of any honest intent on your part (and I
don't doubt you honestly want to give the RFC a fair go), selectively
working very actively to get around the rules and timeline will
inevitably appear highly unilateral, political and abusive to others,
especially when you complain about others opposing the attempt and
it's literally just you doing it. You have fired that appearance up
whether you perceive it as deserved or not. You keep calling out
technicalities and complaining/criticising or misdirecting whenever
someone questions you on them, and that dismissive attitude will
unintentionally rub some people the wrong way entirely.

Now, the way I see it, is that the established process has fucked up
;). The basic scalar types would not be objectionable in any way two
weeks ago, but we don't have two weeks and nobody ran with a basic RFC
when time was available. We're in the middle of a mad scramble of RFCs
rushing to a vote. The real elephant in the room for many will be why
the PHP7 wasn't just extended once it became obvious that a last
minute rush was inevitable, including an insanely controversial set of
them. Hindsight is always great and perfectly useless to the present
time, and it's all kinds of frustrating. I understand your
perseverance, but we seem stuck with this situation and it won't look
any prettier tomorrow either. Whatever the outcome, PHP 7's process
will be talked about for a very long time.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com

Lester Caine

11 years ago

On 15/03/15 21:33, Anthony Ferrara wrote:

> However, it has become exceedingly clear to me that this good faith
> has not been reciprocated. The understanding that we had when both
> proposals opened has now been violated. Rules have been broken and
> politics are ensuing in an attempt to sabotage this proposal. Rather
> than working together, "unofficial polls", backdoor politics and poor
> behavior have created yet more toxicity.

It is clear that while a majority of people may want type hinting in
PHP7, just how to achieve that is NOT agreed. Even nudging THIS RFC just
over the target vote still leaves many problems. Just how many people
are voting for strict mode only? How many for ANY weak mode and how many
would accept an alternative weak mode mechanism if strict mode was was a
separate option which could be optionally added.

Even claiming 'victory' would be a hollow win if what is included is
simply ignored by 1/3rd of the users. You obviously desperately want
strict mode, and I see no problem with that being an extension on top of
a weak mode implementation, but is the bundled weak mode really what
others want?

Even Zeev want's type hinting just not in the way currently being
proposed here, and perhaps a lot of the opposition is to that to the
detriment of adding type hinting - if we have to have it.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Yasuo Ohgaki

11 years ago

Hi Anthony,

On Mon, Mar 16, 2015 at 6:33 AM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> I have decided to close the vote on my Scalar type declarations RFC.
>
> When I added the wording "or the date that voting closes on a
> competing RFC." to the voting timeline of the RFC, it was in the
> understanding that it was a good faith effort on the part of Zeev and
> the competing RFC for the best of the project. I was advised against
> doing so by several people. I still chose to show the good faith and
> attempt to work with people rather than against them.
>
> However, it has become exceedingly clear to me that this good faith
> has not been reciprocated. The understanding that we had when both
> proposals opened has now been violated. Rules have been broken and
> politics are ensuing in an attempt to sabotage this proposal. Rather
> than working together, "unofficial polls", backdoor politics and poor
> behavior have created yet more toxicity.
>
> For this reason, I consider the good-faith clause violated.
>
> Rather than drag this vote on end, and rather than be accused of
> closing "when convenient", I am choosing to move up the ending day to
> put an end to the drama.
>
> Therefore, I am closing votes on this RFC effective tomorrow, March 16th.
>
> https://wiki.php.net/rfc/scalar_type_hints_v5#vote
>

The most serious issue of this RFC is

- It hides bugs that should be fixed in both weak and strict hint mode.

The reason why we would like to have scalar type hints is to "eliminate
type related bugs", not "hiding type related bugs".

Bugs will be hidden with this proposal. I'm sure this is not what you want
and almost all of us does not want if not all.

Coercive type for general developers and strict type for library developers
will
eliminate more type related bugs, more natural to average PHP users. IMHO.

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.

I hope both you and Zeev work together to satisfy most needs because
hiding bugs are not good thing to do.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Pierre Joye

11 years ago

On Mon, Mar 16, 2015 at 12:40 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Anthony,
>
> On Mon, Mar 16, 2015 at 6:33 AM, Anthony Ferrara <ircmaxell@gmail.com>
> wrote:
>
>> I have decided to close the vote on my Scalar type declarations RFC.
>>
>> When I added the wording "or the date that voting closes on a
>> competing RFC." to the voting timeline of the RFC, it was in the
>> understanding that it was a good faith effort on the part of Zeev and
>> the competing RFC for the best of the project. I was advised against
>> doing so by several people. I still chose to show the good faith and
>> attempt to work with people rather than against them.
>>
>> However, it has become exceedingly clear to me that this good faith
>> has not been reciprocated. The understanding that we had when both
>> proposals opened has now been violated. Rules have been broken and
>> politics are ensuing in an attempt to sabotage this proposal. Rather
>> than working together, "unofficial polls", backdoor politics and poor
>> behavior have created yet more toxicity.
>>
>> For this reason, I consider the good-faith clause violated.
>>
>> Rather than drag this vote on end, and rather than be accused of
>> closing "when convenient", I am choosing to move up the ending day to
>> put an end to the drama.
>>
>> Therefore, I am closing votes on this RFC effective tomorrow, March 16th.
>>
>> https://wiki.php.net/rfc/scalar_type_hints_v5#vote
>>
>
> The most serious issue of this RFC is
>
>  - It hides bugs that should be fixed in both weak and strict hint mode.

I disagree, and I won't discuss why again. You misunderstood how it
works or did not test it. Not sure which :(

> 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.

> 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?

> 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.

--
Pierre

@pierrejoye | http://www.libgd.org

Yasuo Ohgaki

11 years ago

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.

>
> > 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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Yasuo Ohgaki

11 years ago

Hi all,

On Mon, Mar 16, 2015 at 11:16 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

>
>
>>
>> > 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.
>

Another common example is database's NUMERIC types.

Database's NUMERIC type has much higher precisions. PostgreSQL has up to
131072 digits
before the decimal point; up to 16383 digits after the decimal point.
Casting to int/float drops
data.

SQLite has type affinity so it can hold any number (or even string etc) in
INT fields. Casting
drops data just like PostgreSQL's NUMERIC type.

Average users did write code like

$sql = 'SELECT * FROM some_table WHERE id='. (int)$id;

even under 32 bit platforms. I'm sure there will be many users who writes
invalid/buggy casts.
It's buggy code even under 64 bit platforms as PHP only support "signed
int" by default.

What we really need is decent conversion rules (it's OK to have new one
since we don't have
it before) that helps users to find bugs in PHP. Users can protect
themselves by additional
code, but why don't we provide it even if there is the code for it?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Dennis Birkholz

11 years ago

Hi all,

Am 16.03.2015 um 03:16 schrieb Yasuo Ohgaki:

> 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.

please, if check_num_range() would be a build-in function, the outcome
would be exactly the same.

If $num contains something like "100 dogs", you get a notice:
http://3v4l.org/fnuAc/rfc#tabs

If $num contains rubbish, you get a catchable fatal error:
http://3v4l.org/UStfP/rfc#tabs

If you handle notices like errors, everything is fine for you. (And you
should do that!)

If you bring up an example to prove a point, please test it beforehand.
If you have strict mode not enabled, there is exactly no incentive for
you to always use casts.

Greets
Dennis

Yasuo Ohgaki

11 years ago

Hi Dennies,

On Mon, Mar 16, 2015 at 11:36 AM, Dennis Birkholz <dennis@birkholz.biz>
wrote:

> Am 16.03.2015 um 03:16 schrieb Yasuo Ohgaki:
> > 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.
>
> please, if check_num_range() would be a build-in function, the outcome
> would be exactly the same.
>
> If $num contains something like "100 dogs", you get a notice:
> http://3v4l.org/fnuAc/rfc#tabs
>
> If $num contains rubbish, you get a catchable fatal error:
> http://3v4l.org/UStfP/rfc#tabs
>

My point is "Coercive type" can find/detect invalid inputs, while both
"Weak and Strict type" cannot.
Writing solid code is upto users with respect to correct conversion
handling. I'm not saying "Coercive
type" is perfect, but much more helpful.

Coercive type RFC helps to find very hard to detect/notice bugs, while
"Weak and Strict type" cannot.
This is very important difference to me because I saw many codes like this
with source code security check,
as well as buggy code with external resources like databases.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Pierre Joye

11 years ago

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.

Yasuo Ohgaki

11 years ago

Hi Pierre,

On Mon, Mar 16, 2015 at 12:31 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> > 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.
>

Whether we like or not, languages that support type safety are getting
popularity
even for web app development in these days. What Zeev is proposing is
common
conversion rules that many languages support already. If we are going to
support
type safety in some forms, we should try to adopt well established rules if
it is
available. I'm not objecting ZVAL type check only strict typing, but I'm
suggesting
Zeev's proposal is more suitable for weakly typed PHP. It works well with
strict type
also.

Introducing type safety is the objective of scalar type hints. In other
words, let users
enjoy less bug programs by systematic support. IMO. What we should think is
"do
it right or not". Hiding type related bugs by enforcing C language like
type is not good
at all. IMHO.

I'm 100% sure that users will have bad codes with this RFC from my code
auditing
experience. In contrast, Zeev's proposal will prevent "bad codes" nicely
and effectively.
That's the reason why I prefer the proposal.

PHP is made to be a nice an easy web app language. It's clear to me which
one is
preferred choice for introducing type hints for "now".

I understand concern about old code compatibility. If currently proposed
migration term
is not enough, we may extend it by other RFC. There is enough time until we
introduce
destructive change. We may change migration period at any time with users
feedback.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net