Re: [RFC] Scalar Type Hinting With Casts (re-opening)

On Thu, Jul 24, 2014 at 11:03 AM, Pierre Joye <pierre.php@gmail.com> wrote: > On Thu, Jul 24, 2014 at 10:52 AM, Pierre Joye <pierre.php@gmail.com> wrote: >> On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf <php@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