> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara > Golemon > > > 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.
I'll propose *leading* and *trailing* whitespaces :) This doesn't cost much and can prove useful. > > 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". 'numeric' can be implemented in two ways : a union type, or a new zpp type. I think I prefer the flexibility of union types. Maybe we'll have to include it in the first release, finally :) > > 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... I prefer defining four new 'strict' ZPP types for int, float, bool, and string (others are already strict). This way, the function decides what it accepts, not the user. Anyway, if we implement union types as strict-only, we will need these types. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
