Hi Andrea, In you proposal you disable declaration of classes with names, that may be used for scalar type hints - Int, Float, ...
What do you think about using only lowercase type names for scalar type hints? In this case we won't have to introduce any limitations. function foo(int $a) // expects integer function foo(Int $a) // expects instance of class Int Thanks. Dmitry. On Tue, Feb 3, 2015 at 12:40 AM, Andrea Faulds <a...@ajf.me> wrote: > Hey everyone, > > > On 2 Feb 2015, at 16:50, Andrea Faulds <a...@ajf.me> wrote: > > > > The implementation does work for testing. I still need to write tests > for return types but they seem to work. Parameter types are fully-working, > though, and they have extensive tests, so I know they’re working fine and > you could add them to an existing project. > > > > Strictifying an existing library is a good idea. I’ll try “strictifying” > one of my bigger personal projects (PictoSwap, a 3DS browser application > with a PHP backend) and see how it goes. I expect it’ll be fairly smooth, > we’ll see. > > I just went and did this on PictoSwap, it was fairly painless. It’s quite > a small application, to be fair, but it is “real-world code”. > > First, I compiled my branch with the following configure command: > > YACC=/usr/local/opt/bison27/bin/bison ./configure --enable-debug > --enable-phpdbg --disable-all --with-gd --enable-pdo --with-sqlite3 > --with-pdo-sqlite --enable-session --enable-json > > Ignore the YACC=, I only need to do that because OS X is weird. As you can > see, PictoSwap requires Gd, PDO-SQLite, Session and JSON. > > Then, I ran my site with the freshly-compiled version of PHP. Actually, > that’s not quite true - I compiled several times, each time finding an > error because of a missing extension. Eventually I got to this configure > line which included all the ones my app needed. > > Second, I added declare(strict_types=1); to each file along with type > hints. I did this file by file, and tested with each file. > > For most of the files, nothing was broken by the addition of strict type > hints. However, some files did cause issues. > > When I added hints to my graphics functions in include/graphics.php and > turned on strict types, I got an error because of a type mismatch, which > lead to me discovering a bug. It turns out I’d been assuming that gd takes > float pixel positions, but it actually takes integer pixels! This means > that those crucial .5s had been truncated off all this time, and I was > none-the-wiser. I added explicit integer casts. Now it’s obvious that the > results are being truncated. > > Adding strict hints to include/user.php, which includes the “business > logic” as such turned up the most issues. It showed me a few different > things. > > One thing I learned was that return types are crippled by the lack of > nullable returns. For most of my functions, I need to return TRUE (success) > or a string (error message). I’d be fine with switching to NULL (success) > or string (error) so it’s hintable, but I can’t actually do that, because > we lack nullable returns. That means I’m omitting return types on most of > my functions, unfortunately. I hope that the Nullable Types RFC can pass > and fix this. > > Another thing I learned was how I really needed to convert the values > going into and coming out of my database (SQLite 3, in this case). Turns > out most of the data in there was strings, as SQLite is dynamically-typed, > and so my JSON output was ending up filled with strings, where it should > have had numbers or booleans. Type mismatch errors allowed me to spot where > this was happening. It’s only because JavaScript is similarly merciful to > PHP that my web app worked at all! > > I also learned that my session data didn’t have correct types: the user ID > had ended up a string, not an integer. This was trivially fixed, but > something I wouldn’t have noticed without strict typing. > > Now, the addition of type hints to include/user.php broke my web-facing > code (htdocs/api.php), because I wasn’t converting types properly. However, > this only broke it when it used strict typing mode. If I turned off strict > typing mode, as I expected, PHP happily converted the types and everything > worked swimmingly. The fixes weren’t that difficult, but not having to make > everything strict at once made adding type hints easier, because I could > disable strict types in code that wasn’t yet ready and my app would keep > running fine, then turn on strict types one it was updated. > > The end result of this was better code, and I spotted some errors. The > migration was eased, as I had hoped, by the ability to make some files > strict and others weak. > > It also shows that my web app works fine without modifications on PHP 7, > which is great. > > Admittedly, my web app is quite small. But I think this makes a good case > for the usefulness of this RFC, and in particular of the declare() system, > and strict hints vs. weak hints. :) > > You can see the diff here: > https://github.com/TazeTSchnitzel/PictoSwap/compare/php7-strict > > Thanks! > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
