> De : Andrey Andreev [mailto:n...@devilix.net] > > > If we still see that employing the strict(er) rules is very noisy with > > internal functions, a more appropriate option may be introducing new > types > > into ZPP, that would correspond to the new rules we introduce in the > > userland type hints, and requiring extension authors to explicitly move to > > them where they believe it's appropriate. That will allow extension authors > > to make their choice regarding their APIs, similarly to the process that > > will happen in userland. > > And that brings us back to square one ... Expose only 1 tool to > userland, but then give two options to the much less-populated crowd > of extension developers. That doesn't make sense to me.
I must say 'no'. That's completely different of dual-mode, as it was not clear, but the types we would add to ZPP would be also available in userland. The objective is to maintain a full consistency between userland, internal funcs, and documentation. This is so true that we'll probably, in the future, introduce ZPP supported specialized types, like path, to userland. I am also quite sure that we'll add a set of strict types, for the few cases where zval type *really* matters (like sorting and other 'special' stuff). But we are not intending to make it more complex than needed for a first release. We all need to practice before identifying additional needs. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php