The 0.1 RFC version was mentioned a lot as a good compromise by many
people and had major support.
People keep saying this like it's a thing, but I and others are vehemently
opposed to this as a solution. The only thing weak hints accomplishes is
the illusion of safety without actually providing it. You can already
perform lossy casts on your inputs. Weak hints, IMHO, is the worst
available option and I know plenty of folks who agree with me.
Any proposal to the scalar hints problem that doesn't definitively error
out in the (int) "apple" case is a non-starter for me; I believe such
solutions are disingenuous at best and dangerous at worst.
I wish people would stop suggesting that there was universal support for
weak hints. There wasn't, and I suspect this dialogue was only avoided
because the proposal gave a good option to those in favor of strict hints.
-----Original Message-----
From: rdlowrey@gmail.com [mailto:rdlowrey@gmail.com] On Behalf Of
Daniel Lowrey
Sent: Monday, February 16, 2015 5:13 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: I quit.The 0.1 RFC version was mentioned a lot as a good compromise by many
people and had major support.Any proposal to the scalar hints problem that doesn't definitively error
out in
the(int) "apple"case is a non-starter for me; I believe such solutions
are
disingenuous at best and dangerous at worst.
Weak type hints the way Andrea proposed them in v0.1 actually did not accept
"Apple" as an int (wiki.php.net/rfc/scalar_type_hints?rev=1420209410):
"†Non-numeric strings not accepted. Numeric strings with trailing characters
produce a notice."
† applied to both int and float type hints in case of string inputs.
Judging by both this and Anthony's message from a couple of days ago giving
the same Apple example, perhaps v0.1 wasn't clearly understood.
Zeev
-----Original Message-----
From: rdlowrey@gmail.com [mailto:rdlowrey@gmail.com] On Behalf Of
Daniel Lowrey
Sent: Monday, February 16, 2015 5:13 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: I quit.The 0.1 RFC version was mentioned a lot as a good compromise by many
people and had major support.Any proposal to the scalar hints problem that doesn't definitively error
out in
the(int) "apple"case is a non-starter for me; I believe such
solutions
are
disingenuous at best and dangerous at worst.Weak type hints the way Andrea proposed them in v0.1 actually did not
accept
"Apple" as an int (wiki.php.net/rfc/scalar_type_hints?rev=1420209410):"†Non-numeric strings not accepted. Numeric strings with trailing
characters
produce a notice."† applied to both int and float type hints in case of string inputs.
Judging by both this and Anthony's message from a couple of days ago
giving
the same Apple example, perhaps v0.1 wasn't clearly understood.Zeev
Perhaps I should've been more explicit: "Numeric strings with trailing
characters produce a notice." is also unacceptable.
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);
^ It's my own personal opinion, but as I said before and still believe,
allowing such behavior is disingenuous at best and dangerous at worst.
2015-02-16 17:26 GMT+02:00 Daniel Lowrey rdlowrey@php.net:
-----Original Message-----
From: rdlowrey@gmail.com [mailto:rdlowrey@gmail.com] On Behalf Of
Daniel Lowrey
Sent: Monday, February 16, 2015 5:13 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: I quit.The 0.1 RFC version was mentioned a lot as a good compromise by many
people and had major support.Any proposal to the scalar hints problem that doesn't definitively
error
out in
the(int) "apple"case is a non-starter for me; I believe such
solutions
are
disingenuous at best and dangerous at worst.Weak type hints the way Andrea proposed them in v0.1 actually did not
accept
"Apple" as an int (wiki.php.net/rfc/scalar_type_hints?rev=1420209410):"†Non-numeric strings not accepted. Numeric strings with trailing
characters
produce a notice."† applied to both int and float type hints in case of string inputs.
Judging by both this and Anthony's message from a couple of days ago
giving
the same Apple example, perhaps v0.1 wasn't clearly understood.Zeev
Perhaps I should've been more explicit: "Numeric strings with trailing
characters produce a notice." is also unacceptable.curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);
^ It's my own personal opinion, but as I said before and still believe,
allowing such behavior is disingenuous at best and dangerous at worst.
This bickering already jeopardized the type hinting RFC's how many times? 3
as I recall?
Right now we need a breakthrough event - get type hints into the language
at all. The most sensible thing to do it is to add basic type hints that
work like the current conversion rules, maybe add some notices/warnings for
some cases. Or adjust the conversion rules themselves in line with the new
type hints.
Whatever type of typehints I like personally better does not matter, what
matters is what is fitting the language and is reasonable. And what leaves
improvement avenues for the future. It is better to make smaller changes,
than making a god type feature and then realizing that, if something got
messed up badly, you can't fix it, because it is already a BC issue.
I always liked the incremental nature of PHP maturing and adding features.
Just stick with it, do the typehints in increments. Be patient.
It's not like next release after 7.0 is going to take a years like before,
we have releases every year now.
On Mon, Feb 16, 2015 at 11:00 AM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:
This bickering already jeopardized the type hinting RFC's how many times?
3 as I recall?
Zeev was kind enough to reach out privately prior to your message and we
began exchanged mails trying to better understand each other's point of
view. In any case, this is certainly the wrong thread for discussions of
the technical merits of a specific proposal. Let's keep it on-topic :)
Am Mon, 16 Feb 2015 18:00:41 +0200
schrieb Arvids Godjuks arvids.godjuks@gmail.com:
Hallo,
Right now we need a breakthrough event - get type hints into the language
at all. The most sensible thing to do it is to add basic type hints that
work like the current conversion rules, maybe add some notices/warnings for
some cases. Or adjust the conversion rules themselves in line with the new
type hints.
Split a scalar typehints RFC in several smaller RFCs, problems, questions, discussions?
- Should PHP support scalar type hints?
- What are the advantages of the typehints for objects?
- What are the advantages of strict/weak types?
- Be aware of the type handling of internal functions:
- float silently converted to int
str_repeat ( string $input , int $multiplier )
echo str_repeat('a', 3.7); - ...
- float silently converted to int
- Validation of user submitted data in frameworks is already strict
type checking - ...
tschuess
[|8:)