Thank you for clarifying some things :)

>    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.
>
>
Yeah, I don't want to start a discussion on that now nor start a (probably
already repeated) war on it, but I think those principles are dead since
very long time...


> >    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.
>
>
That's not about working with scalar wrappers (which, anyway, would be very
useful in Doctrine). It is about casting any object to array... `((int)
$dbTableGateway)` could implicitly cause an sql `COUNT` query and stuff
like that :) Maybe I'm too java-ish, but those look like good improvements
to me :)

Reply via email to