> 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

Reply via email to