All,
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
Thank you
Anthony
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
Dennis,
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
-----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
ChangeHowever, 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
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
-----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
ChangeHowever, 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
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
-----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
ChangeHowever, 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
to the drama.Talk about changing the rules mid-flight.
Zeev
-----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
ChangeHowever, 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
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
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.
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
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.
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
Hi Pierre,
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
Hi all,
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
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
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#tabsIf $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
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.
Hi Pierre,
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