On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 02/16/2015 09:48 PM, Sara Golemon wrote: >> Second, I should clarify that while the HHVM runtime performs >> coersion, the hack type checker is strict. So my original statement >> was inaccurate. As far as hack is concerned, it's simply strict. >> Period. > > With both the default (partial) type checking and strict enabled, my > number_format() example in Hack produces: > > ... > > Please correct me here if I somehow ran these incorrectly. I did put > some deliberate type errors into my userspace code and hh_client caught > those nicely, so it seems like it was working, but it didn't catch > anything when it came to calling the internal API functions. > The mechanisms are strict, but the definitions, in hack, are untyped, so there's nothing to validate:
hphp/hack/hhi/stdlib/builtins_string.hhi: function number_format($number, $decimals = 0, $dec_point = ".", $thousands_sep = ","); We left a lot of stuff untyped from hack's point of view precisely because so much of PHP's APIs are non-sensical. Have you looked at what chr() does with bad types lately? Yikes. > So, you keep asking what I would support. I would like to see an RFC > along the following lines: > > 1. Tighten up the type coercion for the "1000 dogs" case although we > have to look at whether there is a problem with some database APIs > returning space-padded fields so "1000 " would now break. > Hopefully that is fringe enough to not break the world. > Hopefully, though I think that we could embrace the idea of trailing space as insignificant. > 2a. In strict mode, tone down the strictness and allow non-lossy > coercion including int->float. And yes, I know in really edge cases > that isn't technically non-lossy, but for all practical purposes it > is. > Nod. Ze'ev called for this too. > 2b. A much more flexible system for specifying multiple types. I should > be able to say that my function takes something that looks like a > number if I choose and still take advantage of stricter typing for > other parameters. > Union types. I'm hear a lot of support for this concept, and not exclusively from one camp. Perhaps with a psuedo-type defined somewhere to account for the half-type "numeric string". > 3. Don't turn on crazy-strict mode for internal functions that weren't > designed for that. Instead provide the same ability as userspace gets > for developers to gradually design their APIs to be stricter if they > so desire allowing both Hack and PHP to implement a stricter > curl_setopt(), for example. > Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode? Or something passed to the arg_info struct? The details are secondary, but you get my meaning... -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
