Hi!
Right. So we would have two APIs for types - one coercing (for internals)
and one strict (for user functions), which would work in entirely different
way. Is that good?
How is that different from what we have already?
Well, it's different in a way that right now we have typehints only for
classes and arrays (which work the same internal and external) and
conversions for internals and some places user code (which use the same
logic, just in user code you can't apply them to function parameters
automatically).
With this patch, we won't have one logic anymore - we'd have two logics
- one for typehinted functions (reject everything that doesn't match the
type) and one for the rest of the language (try to coerce types). Two
logics in one language is usually not good.
Internally you type hint (arginfo) what you want, in userland you'll
be able to do that too (int $foo).
No, internal typehint doesn't work the way "int" typehint works with
this patch. Internal typehint (zend_parse_parameters) do conversions,
see zend_API.c. Only typehint that would resemble what internals do is
"numeric" (well, and "scalar", but it doesn't really have internal
counterpart).
I don't understand what "work entirely different" you are talking
about. This is how PHP already works.
No, that's exactly how PHP _doesn't_ work - there's always type
coercion, not just matching of zval types.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
