Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97708
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.51 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <1C.D0.30525.402B6785@pb1.pair.com>
References: <MWHPR02MB24771DF68193D22668A6EE63BF660@MWHPR02MB2477.namprd02.prod.outlook.com>
 <alpine.DEB.2.20.1701111540260.4733@whisky.home.derickrethans.nl>
 <MWHPR02MB24778BAD673E0A28C300EAACBF660@MWHPR02MB2477.namprd02.prod.outlook.com>
 <CAFMT4NqrBPppSLOL-dZ-xdU1kMp8PzTRw5s5WsVZPnnydfM2fA@mail.gmail.com> <1C.D0.30525.402B6785@pb1.pair.com>
Date: Wed, 11 Jan 2017 15:38:55 -0700
Message-ID: <CAFMT4NovHtFkXzxox2aHN2fs-DzUWdBLouPPUW6XR91ybZwcCg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Change in type-hint representation
From: levim@php.net (Levi Morrison)

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.