On Thu, Jul 24, 2014 at 11:03 AM, Pierre Joye <pierre....@gmail.com> wrote:
> On Thu, Jul 24, 2014 at 10:52 AM, Pierre Joye <pierre....@gmail.com> wrote:
>> On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf <p...@bof.de> wrote:
>>> Hi,
>>>
>>> there is, it seems, something missing from both the RFC and the
>>> discussion, as far as I read it. Sorry if it came up before, it was a huge
>>> amount of mails...
>>>
>>> How does the proposal affect method compatibility between
>>> subclasses and baseclasses? Will two methods there, differing in the
>>> scalar type annotations of one of their arguments, elicit STRICT
>>> warnings, like object type annotations do?
>>
>> I think it should behave like class arguments do.
>
> I should be more precise :)
>
> say:
>
> function i(integer $i)
> function f(float $f)
> function s(string $s)
>
> $i = 12;
> $f  = 1.234;
> $s = "abcdef";
>
> For integer arguments:
>
> Works:
> i($i);
>
> Fails:
> i($f);
> i($s);
> i(new StdClass);
>
> float fails as the argument cannot be an integer without lost of
> information. It is a mis-usage of this function argument and the
> intend of the caller can only be guessed and can only lead to bugs.
>
> For float:
> Works:
> f($i);
> f($f);
> integer is, if I take the class behavior as example, like a float,
> same "interface", fully compatible.
>
> Fails:
> f($s);
> i(new StdClass);
>
> For string, every scalar should work as both float and integer are
> easily converted to string, we can compare them to objects with a
> __toString method. I could live with strict too here but implicit
> string conversion makes sense here. Float precision setting is used
> for the decimal precision.
>
> Arrays and objects without __toString fails, obvioulsy.

and to clarify this, after I got some questions/comments on irc etc.:

f.e.
foo(int $a) {
var_dump($a===123);
}

foo(123) >> true
foo("123") >> true
foo("123a")>> error, bad arg

same for float. The cast happens, it would not make sense if not :)

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to