Re: Change in type-hint representation

On Wed, Jan 11, 2017 at 3:30 PM, Andrea Faulds <ajf@ajf.me> wrote: > Hi Levi, > > Levi Morrison wrote: >> >> As part of this effort can we refactor the IS_LONG, IS_ARRAY, >> IS_OBJECT, etc macros to use an enum? Maybe zend_type_code >> if you >> like the code name for it? Also we already use >> "kind" in the AST; >> should it be ZEND_TYPE_KIND and >> zend_type_kind instead? > > > C's enum members always have the type int. However, > typically PHP uses the > smaller zend_uchar for representing a type code. I guess this > is why we > don't use an enum already. This is not true; rather they are only required to support values that can be held in int. Implementations are free to compact it. However it is an issue I had forgotten about, and it is certainly something to keep in mind. > Having a typedef of zend_uchar for this purpose would be great, though. It > would make some function signatures more obvious (e.g. is_numeric_string and > friends return a zend_uchar for the type of the result, and it'd be clearer > this is the case). Yes, at least *something* would be nice if enum is problematic.