Based on conversations here and elsewhere on the internet, I'd like to put forward a rough gameplan for scalar types which I hope addresses most concerns. This is back-of-the-napkin and I'm not asking for a committed yes/no, just pre-rfc set of thoughts.
Please don't get hung up on specific names, we can debate those in the coming week(s), I'm only looking for large architectural issues. 1) Introduce scalar types for primitives: bool, int, float, string, resource, object (we already have array) 1a) Introduce meta-types as pre-defined unions (we can add custom unions in a later rfc). A possible list may be as follows (again, we can argue what's in this list separately): * mixed: any type * scalar: (null|bool|int|float|string) * numeric (int|float|numeric-string) * stringish (string or object with __toString()) * boolish (like mixed, but coerces to bool) * etc... 2) Define a way to enable "strict mode" (we'll be weak by default). 2a) Userspace impact: Strict mode will throw a recoverable error on type mismatch. Weak mode will coerce the type according to conversion rules (See #3), throwing a recoverable error if coercion isn't possible. 2b) Internal impact: The same rules apply to internal functions as userspace functions HOWEVER, we use the types present in ZEND_ARG_INFO structures, not zpp. This has the net effect that every internal function remains effectively untyped unless specifically opted in by means of updating their arg info struct. In weak mode, internal functions coerce according to conversion rules. 3) Tighten up coersion rules for weak mode. i.e. "10 dogs" for an int is a violation, but "10" is acceptable. 3a) Userspace impact: We're in a clean slate state, so this is "safe" from a BC perspective. 3b) Internal impact: Again, behavior remains unchanged unless the ZEND_ARG_INFO struct has been modified to add proper typehints. If typehints have been added, then the more aggressive coersion rules apply during typehint validation. I really want to underline the design expressed in #2b and #3b. zend_parse_parameters()'s types have been removed from the equation in this proposal. This means that, until someone audits a given function and makes the decision to give it a type, it will effectively behave as though always weak, regardless of the caller's flags. This enables us to give the same contractual behavior internally and externally, while still implicitly treating internal functions as a bit special for the purpose of moving forward. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
