> > Of note, the scalar type hinting I've outlined does not automatically > perform casts...
Thank you for your answer. Maybe, this exact fact is what I don't like about your suggestion. Please read the following RFC, where Lukas Smith and Zeev Suraski explain very well why strict type checking without auto-casting is a not a great idea. Of course it is just an RFC, but I find it quite correct. https://wiki.php.net/rfc/typecheckingstrictandweak My concern is that if your suggestion is adopted (as it is, without auto-casting) then an eventual introduction of auto-casting will be impossible without breaking BC. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/1 Adam Jon Richardson <adamj...@gmail.com> > On Thu, Mar 1, 2012 at 8:33 AM, Lazare Inepologlou <linep...@gmail.com>wrote: > >> Yes, I agree, the casting (or the failing to cast) has to happen on >> entry, for the reasons that you have very well explained. >> >> However, I cannot understand what it means to cast an object to a scalar. >> Does it always mean casting to string? Wouldn't that be slow in many cases? >> Simple example: >> > > I'm not sure I understand, so if I mischaracterize your concerns, please > let me know. > > Of note, the scalar type hinting I've outlined does not automatically > perform casts to any particular type of scalar. Rather, it would be the > programmer's responsibility to perform the cast (as I performed in my > example.) This way, only necessary, reasonable casts are performed, and > information loss can be avoided. > > That said, in terms of performance, PHP's type juggling performs these > types of casts all the time, so I don't think I'd be concerned. Any time we > check for equality using ==, perform string concatenation with ints, etc., > PHP's beautiful type juggling automatically performs these conversions for > us without any effort on our part. I've never seen where this is the source > of any performance issues in my profiling, but I must admit that I don't > know the internals well enough to preclude this from ever being an issue. > > class A { >> public $value = 1234; >> public function __toString(){ return (string)$this->value; } >> } >> >> function foo( int $x ) { // here "int" is used as an alias to "scalar" >> as you suggest >> return $x + 1; >> } >> >> $a = new A; >> foo( $a ); // casting $a to scalar upon calling, as it is possible >> after all >> >> In this example, the integer value will have to be cast to a string only >> to be cast back to integer (unless something else happens under the hoods >> that I am not aware). >> > > Speaking to your example, it would throw a catchable fatal error because > the variable $a contains an object of type A and the function foo expects a > scalar. The object would first have to be cast to a scalar. However, as you > pointed out, currently objects can only implement the __toString() method > (i.e., there's no __toInt, etc.), so one can't directly cast an object to > an int. > > This seems contrived, though, because in the case of your example, if a > function expects an integer, wouldn't you just call it with the appropriate > object property: > > foo ($a->value); // works because the value property is a scalar (int) > > Thanks for your commentary :) > > Adam > >
