From: Marco Pivetta [mailto:ocram...@gmail.com] > > tl;dr: "strict type hinting" and "Boxing based type hinting" (the second one > with some changes). > > Just read through it, and I was unaware there's still ideas to continue > working on type hinting in PHP.
There's been some recent discussion facilitated by understanding past fears and embracing some foundation principles as requirements of a successful solution (which solves a major problem with the scalar typing discussions from the past.) > That's good news, at least for me :) > I'm just lurking around here, but if my thoughts can help, here they are. > > Here's a short mapping of considerations related to the various > implementations exposed on that blog post: > > 1. Strict type hinting (also aliased by me "YES please, yes!"): If you want scalar typing you'll have to move past this. I go into this a little below, but you should also look through the arguments in the archives. This is too strict (more strict that C++ actually). There are some rock solid arguments that have basically shut the door on this one forever. It will never pass a vote. > 2. Unenforced type hinting: This almost happened in 5.4, but eventually got pulled. More interestingly, the *community* rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...). > 3. Casting weak type hinting: Silently casting and discarding lost data is a huge problem and ultimately doesn't offer any substantial benefit. This was discussed previously. Also creates a dead end. > 4. Strict weak type hinting: This realm is the most likely to succeed because the core already does something like this for internal functions (via zend_parse_parameters). This balances utility (enforcing the type) with fundamental language design principles (juggling). You need to understand the fundamental language principles to understand why any solution MUST lie somewhere in this realm. Remember that: 1.2 === "12"; "2"+"2" === 4; substr(12345, "2") === "345"; This type juggling affects the language in all sorts of ways. For example, PHP uses '.' for concatenation (not '+' like most similar languages) which ensures that there is no ambiguity as to whether you are operating against the integer value or the string value. PHP is designed so that you generally don't have to care whether a value is ACTUALLY an integer or a string internally, it will be treated as whatever type you use it as. In PHP int(2), float(2.0), and string("2") can generally be used completely interchangeably with no variation in results whatsoever. When core devs say that "strict typing would make it not PHP anymore", this is what they mean; it would badly violate this core concept. If you want scalar typing, you need a solution that embraces this fundamental design principle. > 5. Boxing based type hinting: This is a hack that's been proposed before, but you don't need to look very far to see why this ultimately breaks down badly. Even aggressive casting additions to the language would not make this work particularly well. Anyone who's ever tried to create a class wrapper for a scalar in C++ (which probably includes the core devs) is not likely to be down with this idea. John Crenshaw Priacta, Inc.
