RE: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
From: Marco Pivetta [mailto:[email protected]]
>
> 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.
Thread (13 messages)