Matthew,
Have you seen the new thread and RFC around this?
https://wiki.php.net/rfc/parameter_type_casting_hints
I went with option A, as I see erroring on cast as a more general
problem. So for consistency, I implemented it exactly like normal
explicit casts...
Anthony
On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney
<weierophin...@php.net> wrote:
> On 2012-03-02, Anthony Ferrara <ircmax...@gmail.com> wrote:
>> Well, there are a few questions about the implementation:
>>
>> 1. *Which* type casting rules should it follow?
>>
>> a. Regular cast rules (like $foo = (int) $foo), where it converts
>> always without error?
>> b. Internal function cast rules, where it warnings on error and
>> prevents execution of the function.
>> c. Current type hinting rules, where if it can't convert cleanly it
>> E_RECOVERABLE_ERRORS
>>
>> Personally, I like C the best. Where if it is passed an invalid
>> value, it attempts to cleanly convert, but errors out if it can't...
>> But I can see other arguments being made...
>
> (c) seems the most sane option ot me as well.
>
>> 2. Should (array) be supported? Perhaps. So at that point, foo(array
>> $bar) would do a "strict" check, and foo((array) $bar) would attempt
>> to cast. But my question would be: what would attempt to cast mean?
>> Should it error out if you pass foo(1)? That's what the internal
>> function cast rules do. And to me that's more obvious than silently
>> converting it to foo(array(1))...
>
> Turn this around and look at it from the current state of PHP:
>
> function foo($bar)
> {
> $bar = (array) $bar;
> }
>
> If you pass a value of 1 for $bar, $bar is then converted to array(1).
> That's what I'd expect the following to do as well:
>
> function foo((array) $bar)
> {
> }
>
> It's casting, and clearly different than:
>
> function foo(array $bar)
> {
> }
>
> which is doing a typehint check.
>
>> 3. Should references be supported? My feeling is yes, they should.
>> So if you do foo((array) &$bar), it would cast the original value (if
>> possible) as well.
>
> I personally would expect casting and references to be mutually
> exclusive -- if you're casting, you're changing the value type, and I
> wouldn't expect a destructive operation like this from passing a value
> to a function/method call.
>
> <snip>
>
>> 5. What about BC breaks? Well, this entire patch (up to this point)
>> wouldn't require one. it's only adding the casting functionality
>> (which is not implemented today), so no problem. Existing code would
>> still function fine.
>
> This is something that should be highlighted. I've seen a lot of folks
> claiming type hinting is viral, and the arguments make no sense to me.
> What your patch is offering is _opt_in_ type casting of function/method
> arguments. You don't _have_ to write your functions or methods using
> them, and for those who do, it should have no side effects on code
> calling it.
>
> I would _LOVE_ to see this as part of PHP.
>
> --
> Matthew Weier O'Phinney
> Project Lead | matt...@zend.com
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
