Re: Strict typing

On Wed, 11 Aug 2010 16:03:14 +0100, Alexey Zakhlestin <indeyets@gmail.com> wrote:

2010/8/11 Ryan Panning <rpanning@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