On Tue, Feb 17, 2015 at 11:03 PM, Sara Golemon <poll...@php.net> wrote:
> 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. > I don't like the way this is heading with regards to internal functions. Apart from better inter-compatibility, the primary appeal of Andrea's proposal was that we have the option to make not only userland function calls strict, but internal ones as well. With these modifications this is lost for all practical purposes. (*) I don't buy into Rasmus arguments about internal functions. They concern one particular edge case (int->float coercion) and I doubt they have much relevance if applied to codebases with pervasive use of typehints (where you can be reasonably sure of the types of your variables). Even if, for the sake of argument, we acknowledge the concern as valid we should be discussing that particular case (int->float coercion) rather than dropping the strict typing for internal functions altogether. I'd personally appreciate to just go back to Andrea's proposal with a tweak to fix the declare() issues. Nikita (*) Where "practical purposes" refers to my assumption that it is very unlikely that we'll add arginfo typehints to the entirety of all bundled functions and the added typehints will not be heavily colored by people trying to shove in weak typing even when strict mode is enabled. For our own good, obviously.
