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. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
