On Wed, 11 Aug 2010 16:03:14 +0100, Alexey Zakhlestin <indey...@gmail.com>
wrote:
2010/8/11 Ryan Panning <rpann...@gmail.com>:
Because the current syntax used for type hinting
classes/arrays is strict. If changed, you would need to specify that
scaler
types are weak but classnames are strict and now you have a WTH moment.
Not really. Class type-hinting is not strict. The only reason why it
looks strict is, that PHP doesn't provide userland ways for
object-casting.
As far as I remember, zend-engine, underneath, actually has hook for
casting. And nothing stops us from supporting such casting with hints,
eventually.
If you're referring to the cast_object handler, the only thing it can
specify in terms of the target type is IS_STRING, IS_OBJECT, etc.
I don't think what we have now and both strategies that are being
considered are directly comparable, so the "the current type hinting*
is/is not strict" and "the new strategy is/is not consistent with current
type hinting" are just rhetoric.
I'm my opinion, what we should strive for is consistency with the only
comparable thing, the current parsing API, zend_parse_parameters. If an
internal function says it accepts an array, it can only take an array**.
If it says it only accepts an object of a certain type, it checks the
inheritance hierarchy***. So the current type hinting implementation is
already consistent with zend_parse_parameters.
Unfortunately, both competing options want to deviate from this:
- The strict side wants a simple, 'gettype' like check, that has nothing
to do with the current API.
- The weak side thinks the current parameter parsing API is a bit loose
(for instance, if I'm not mistaken, all the scalars are automatically
converted to bool), so it's better to create a whole new set of rules,
even though they will still deviate slightly from the current API.
In my opinion, the transition should be made slowly. First, by raising a
warning on the undesirable automatic conversions we don't want, and
finally disallowing them altogether and introducing a compatible
user-space type hinting.
* terminology objections aside
** the rare 'H'/'A', which also take an object, excluded)
*** 'o' can also be given, which accepts all the object types
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
