
PHP7 Gains Scalar Type Hints - pbowyer
https://wiki.php.net/rfc/scalar_type_hints_v5#vote
======
Danack
To explain the slightly horrible fact that there are two modes, strict and
weak with strict mode being enabled on a per file basis; people just couldn't
agree on whether the types should be strict or if they should use PHP's
existing coercion rules. (Or even a 3rd new set of conversion rules, but lets
ignore them).

Having an optional mode per file allows:

People who want to write code with strict types can do so. People who want to
write code with weak types can do so. People who want to write code without
these new fangled types can continue to do so.

All without any issues of compatibility between running code on the current
version of PHP and what will be the next one, and without any compatibility
issues for libraries that are solely written in one mode, being used in
applications that are written in the other mode.

\o/

To be honest, I'm completely in the strict camp - but it's awesome that we've
gotten a solution that should allow everyone to use the mode they want,
without splitting the PHP ecosystem.

~~~
ars
> To be honest, I'm completely in the strict camp

Can you explain why? Are you using PHP in a web context? Because everything
from the web is a string.

So wouldn't it make the most sense to let the functions using the web data
coerce to integer, and just work?

How does putting (int) before the arguments to function help anything?

I actually liked Ze'ev's proposal because it let you be weak while making sure
you did not coerce obviously bad data.

Anyway, as a member of the strong camp, can you explain?

~~~
bad_user
> _Because everything from the web is a string._

I would start by saying that everything, regardless of domain, is just a
stream of bits. Which is completely useless, just like your assertion.

And I know what you meant, but you're also wrong. A JSON object is only a
string before being interpreted. An x-www-form-urlencoded is actually a map in
which values can be arrays instead of primitives. Such forms often correspond
to domain models with a clear definition.

There's also no such thing as " _obviously bad data_ ". All data is good in
the proper context, therefore automatic conversions that try to make this
distinction do not make sense. I don't necessarily know how PHP behaves, but
in another popular language there's a world of difference between " _077_ "
and " _77_ ". There's also a world of difference between integer, floating
point and fixed point and the details are never irrelevant.

~~~
ars
> therefore automatic conversions that try to make this distinction do not
> make sense.

You have to convert it _somewhere_. I don't see how the caller converting it
is any better than the recipient doing it. Having the caller do it seems quite
pointless when the recipient is anyway doing it.

Your answer about how everything is bits was quite useless since you
completely missed the point. Your input is a string, you have to convert it
someplace. Weak mode has the recipient do it. Strict mode you have to do it
yourself, and then the recipient double checks.

I see no value in the second option - the actual conversion in both cases is
identical.

But Danack disagrees, so I asked him to explain. Your answer was not helpful
at all.

~~~
bad_user
@ars, you completely missed my point. Lets go over it again. Tell me how
should the following things convert:

    
    
         77
         077
         77.0

~~~
ars
I GOT your point. I don't care about your point because it is not the question
I am asking.

Why are you answering something I did not ask?

I am asking why does Danack prefer strict mode. There is absolutely nothing in
my question that cares about the specific details how you convert bits to
types, other than that you do.

My question is entirely about WHO does the conversion. NOT about the
conversion itself.

(Oh, and the thing about bad-data has a defined meaning that went over your
head because you are not familiar with the debate here. In this context bad-
data means data loss on conversion. So "1" to 1 is fine, but "1 a" to 1 is
not.)

~~~
bad_user
The conversion itself is very relevant because you cannot establish a default
conversion that should happen, therefore the conversions should be explicit,
answering the WHO. This is why I asked you about what should the conversion
produce in those examples.

And also in the conversion from "1.1" to 1.1 there is loss of information,
because the two representations are not isomorphic. Care to guess why?

~~~
marrs
This is the point that ars is making. He is saying that it has to be a runtime
check and/or conversion because it is coming over the wire, as a string, at
runtime.

So the question he is asking is, if you have to do the check at runtime
anyway, what is the benefit of the type hinting? Isn't it just belt and
braces?

It seems like a perfectly legitimate question to me.

And by the way, to those downvoters who don't seem to be able to tell the
difference between a comment you disagree with and spam, can you please
contribute to the conversation by hitting the reply button or alternatively
get lost? Only you're ruining it for the rest of us. Thanks

------
ZeroCoin
I love PHP.

I think of it as the English language of programming. Picking and choosing all
of the best bits from every other language, and bastardizing them into it's
own everyday use.

~~~
wyager
If I cut off the limbs of a bunch of athletes and glue them together, it
doesn't make a better athlete.

~~~
awalGarg
I hope you don't find analogies like that. It doesn't make sense to compare
athletes to programming languages; that analogy makes no sense at all.

Also +1 to what @Padding says.

~~~
wyager
It's obviously not a precise analogy :)

However, it gets the point across; taking a bunch of bits from disparate well-
functioning systems and smashing them together doesn't guarantee that you'll
get another well-functioning system.

------
jkoudys
Finally! I had a lot of concerns about this, but I think they're mostly
answered by the discussion. I do like the way union types work (at least
nullable types) in Hack, but I think they existing `foo(int $param = null)`
approach is fine for 99% of cases, and those that it doesn't work for can go
back to type-checking at the top of the function (ie do what we have to do for
all scalar types right now).

While I understand the optional strict mode, I do find it quite confusing: it
looks similar to javascript's 'use strict';, and at first glance it sounds
like it should be similar to `error_reporting(E_STRICT)`, yet somehow scoped
to the <?php ?>. Personally I like the `strict namespace` approach they
proposed the most. The argument against is that it will read like everything
in that namespace is strict, when it's actually limited to the file, but I
think it's pretty clear if I read in a.php `strict namespace Qaribou;` and in
b.php `namespace Qaribou;`, that a.php is strict and b.php is not. I really
don't see the ambiguity there.

------
pbiggar
That's right, the PHP community _votes_ on language features.

~~~
TazeTSchnitzel
Though there is a lot of controversy about who is allowed to vote. Currently
it's anyone with a php.net account, which is:

* People who have commit access to git/svn

* Documentation contributors

* Documentation translators

* PEAR package maintainers

* PECL package maintainers

* _Very_ few "community representatives"

~~~
chx
While I won't go even close to the PHP internals list, deciding on the
community representatives will be... interesting. Drupal, which
[http://w3techs.com/technologies/details/cm-
drupal/all/all](http://w3techs.com/technologies/details/cm-drupal/all/all)
powers 2% of the web has an army of subsystem
[http://cgit.drupalcode.org/drupal/tree/core/MAINTAINERS.txt](http://cgit.drupalcode.org/drupal/tree/core/MAINTAINERS.txt)
maintainers. If you open the gates, whom of them will be allowed to and who
won't? Fascinating.

~~~
TazeTSchnitzel
Generally the idea is to give the head of the project a vote.

------
arenaninja
Hooray! \o/

I haven't had a use for this yet, but I'm always amazed by how PHP manages to
move forward without breaking BC.

~~~
AlexMax
> I haven't had a use for this yet, but I'm always amazed by how PHP manages
> to move forward without breaking BC.

This. If I were a Python developer (of the language itself), I would be paying
very close attention to how PHP has handled deprecation and breaking changes.

~~~
TazeTSchnitzel
There's been an effort with PHP 7 to try and avoid a Python 2/3-style
situation. The PHP 5 to 7 jump should be much smaller than from 4 to 5.

~~~
Danack
>The PHP 5 to 7 jump should be much smaller than from 4 to 5.

And also the jump from 5.4+ to 7 is probably smaller than the jump from 5.2 to
5.3.

Although I think the PHP project does need to support versions for longer, the
adoption rate of 7 is going to be quite rapid due to the low barrier of doing
it, and the massive performance and language gains.

------
awalGarg
Yay! <3 PHP.

Also, the moment I read _declare(strict_types..._ , for some reason _" use
strict";_ from ECMAScript flashed in front of me :D

~~~
some_furry
Same idea, except `use \Foo\Bar\Baz as SomeAlias` is already reserved for
namespaces.

~~~
TazeTSchnitzel
Also, we already have use strict; as an easter egg ;)

~~~
scintill76
Exactly how do you trigger the easter egg, and what does it do?

~~~
johnny22
$ php -a

php > use strict;

PHP Fatal error: You seem to be trying to use a different language... in php
shell code on line 1

~~~
Latty
There are some similar gems to be found in Python:

    
    
        >>> from __future__ import braces
          File "<stdin>", line 1
        SyntaxError: not a chance

~~~
awalGarg
Also try doing `import antigravity` from the Python repl ;)

------
Chintagious
Wow, interesting:

"Whether or not the function being called was declared in a file that uses
strict or weak type checking is irrelevant. The type checking mode depends on
the file where the function is called."

That means that my function can have a parameter defined as an int in its
strict file, but if it's called from outside of it, anything can still be
passed to that parameter, right?

I'm not sure how I like that. What if you're passing input from class A into
class BStrict then using BStrict to call a function in CStrict? BStrict and
CStrict are defined as strict, where A is not. Would BStrict then be the one
throwing the error because the "caller" is the issue?

From the description it seems that the parameters are effectively ignored in
BStrict when A calls it.

Am I missing something or does this sound iffy?

Edit: Link for quote -
[https://wiki.php.net/rfc/scalar_type_hints_v5#parameter_type...](https://wiki.php.net/rfc/scalar_type_hints_v5#parameter_type_declarations)

~~~
TazeTSchnitzel
> That means that my function can have a parameter defined as an int in its
> strict file, but if it's called from outside of it, anything can still be
> passed to that parameter, right?

Not at all. It's "weak" typing, not no typing.

A small set of convertible values can be passed and will be converted to the
type you asked for, while other values error as usual.

See the rest of the RFC.

~~~
Chintagious
You're right, I see that now. That's why they went into describing type
conversions too. Thanks for the insight!

------
nnq
Why do we need to duplicate the effort that people (some _very smart_ people,
btw!) have put into Hack ([http://hacklang.org/](http://hacklang.org/)), a
sane strictly typed PHP successor with many other good stuff added?!

(imho, not only _good_ , but _awesome_ stuff, like _XHP_
[https://www.facebook.com/notes/facebook-engineering/xhp-a-
ne...](https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-
write-php/294003943919) and _async /await_
[http://docs.hhvm.com/manual/en/hack.async.php](http://docs.hhvm.com/manual/en/hack.async.php))

And as a bonus, both HHVM.PHP and Hack and are well optimized to run at
Facebook's scale... seriously, let's just leave Zend.PHP rot away in the
trashcan of history and move the f on!

~~~
marrs
Well an obvious reason is all the PHP site that have already been written, are
crucial components in many businesses, and cannot be upgraded to Hack. Those
sites' authors may still want access to all that good stuff.

In fact, this kind of feature may make it easier to convert those applications
to Hack in the future.

~~~
nnq
You can freely mix Hack code and PHP code on the HHVM, calling functions and
classes defined in any PHP file inside you Hack app. Then you can slowly
evolve the codebase to contain more and more Hack and less and less PHP.

That's the _huge point that nobody seems to see._

But then again, considering how many other huge points PHP developers seem to
miss in general, maybe it's better to just let Node.js eat the world :)

~~~
marrs
In that case I take it all back! Sorry, I hadn't realised HHVM was so far
along.

------
dpacmittal
Interesting that Rasmus voted a No for this.

~~~
olemartinorg
Not really, I think. It was exactly as I expected.

I once attended a mini-conference where he did a talk about PHP history. After
the talk, someone asked a question about strict typing. Rasmus really hold on
to the web not having types (just passing strings, as have been pointed out in
other comments here). I remember him saying something like "when the web have
strict types, PHP will have it too".

~~~
Danack
This is actually quite revealing. Some people think that PHP is just used for
the same small web pages it was used for 15 years ago.

Other people would like to use PHP more as a general computing language.

Having optional types takes nothing away from using PHP for simple web pages,
but does make it easier to right analyzably correct programs.

The fact that the founder of a language doesn't want to see it grow is quite
depressing.

~~~
marrs
He doesn't want this particular feature. Considering the amount that PHP has
grown, he obviously does want it to grow.

------
eduard44
Good. Now I just need to wait for PHPStorm to support them ;)

~~~
TazeTSchnitzel
Submit a feature request! ;)

------
ZeroGravitas
So how do you go about using this in both PHP5 and PHP7 at the same time?

Do you need to run a pre-processor to strip them out of the code that runs on
PHP5, while getting the benefit for testing on PHP7?

Trying it naively, PHP5 thinks you want to use a class called "int". And
doesn't like the : for the return value.

~~~
pbowyer
A pre-processor for PHP is a nice idea... like all the ES6 ones for
JavaScript.

------
leeoniya
speaking of phpng, it now scores 1s better on the wordpress unit tests than
just 3 month ago: [https://wiki.php.net/phpng](https://wiki.php.net/phpng)

------
1ris
Can somebody explain this to a non-phper? So PHP got strict types, but only
for Scalars (Ints and floats) and they can be enabled on a per-file basis.
Right?

~~~
Danack
PHP has had type-hints for parameters for several version, but they could only
be used for classes. The new types-hints cover the 'scalar' values (aka not
object) and are int, float, string and bool. They allow a function to declare
what they types of the variables it receives should be like:

function foo(int $x) { // x is guaranteed to be an int. }

The type-hinting for scalars has two modes:

* strict - the parameter passed to the function must be of the exact* type. * weak - the parameter passed to the function will be converted to the correct type.

The strictness depends on what mode PHP was in when the function was called.
This is the right choice as it:

* Allows library authors to write their code in either strict or weak mode.

* End-users to write their code in either strict or weak mode. Or even without using scalar type-hints.

* End-user to be able to choose when they are writing their code do they want their variables to be converted to the type expected by the library automatically, or do they want PHP to give them an error if they accidentally pass the wrong type of variable to a function that is expecting an int.

*except for some widening rules, e.g. you can pass an int where a float is expected, as ints can be converted into float without data loss (for ints less than 2^53).

~~~
johnny22
they could have been interfaces, or arrays too.

------
cwyers
Is this compatible with what Facebook has done with Hack?

~~~
TazeTSchnitzel
There's no fundamental incompatibility. Hack files don't use <?php tags, they
use <?hh tags. I'm sure Facebook will make HHVM handle PHP type declarations
alongside Hack type declarations, though exactly how they'll interact remains
to be seen.

------
spion
I can't find it anywhere in the document - are these statically checked types
or just run time checks (contracts)?

~~~
TazeTSchnitzel
Runtime (like PHP's existing type hints), but they could be checked statically
by IDEs and such. One benefit of strict mode is that it enables much better
static checking than weak mode, because validity is determined by type and
never value.

------
amyjess
What happened to PHP6?

~~~
TazeTSchnitzel
PHP6 was supposed to be this all-singing all-dancing Unicode support release.
It dragged on for years but didn't get finished due to various issues, and in
2008 they decided to just scrap it and roll what they could salvage into 5.3

Since PHP6 died, it made sense to avoid confusion and not name the new major
version 6, since we'd then have two different PHP 6es.

This is not unlike what happened with ECMAScript 4.

~~~
duskwuff
That's funny; I used nearly the exact same phrasing to describe PHP 6 a few
months ago:

[https://www.reddit.com/comments/2qyuhc/new_rfc_for_scalar_ty...](https://www.reddit.com/comments/2qyuhc/new_rfc_for_scalar_types_in_php_7/cnavjpe)

~~~
TazeTSchnitzel
Ah, I may have subconsciously copied the way you said it, I think I've read
your comment before. Sorry about that!

