Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97675
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.68 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "PHP internals list" <internals@lists.php.net>, "Dmitry Stogov"
 <dmitry@zend.com>
References: <MWHPR02MB24771DF68193D22668A6EE63BF660@MWHPR02MB2477.namprd02.prod.outlook.com>
Date: Wed, 11 Jan 2017 16:35:52 +0300
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.ytwld21ec9evq2@nikita-work-box>
In-Reply-To: <MWHPR02MB24771DF68193D22668A6EE63BF660@MWHPR02MB2477.namprd02.prod.outlook.com>
User-Agent: Opera Mail/12.16 (Linux)
Subject: Re: [PHP-DEV] Change in type-hint representation
From: inefedor@gmail.com ("Nikita Nefedov")

On Wed, 11 Jan 2017 15:07:39 +0300, Dmitry Stogov <dmitry@zend.com> wrote:

> Hi,
>
>
> I propose to introduce a unified type representation (zend_type).
>
> Now it's going to be used for typing of arguments and return values.
>
> Later we should use it for properties and other things.
>
>
> https://gist.github.com/dstogov/1b25079856afccf0d69f77d499cb0ab1
>
>
> The main changes are in zend_types.h and zend_compile.h, the rest is  
> just an adoption for new type representation.
>
> I don't think we need RFC, because this is just an internal change that  
> doesn't change behavior.
>
>
> I got the idea working on typed properties together with Bob and Joe.
>
> https://github.com/php/php-src/compare/master...bwoebi:typed_ref_properties
>
> I think it would be better to introduce zend_type and then continue work  
> on typed properties.
>
>
> Any comments?
>
>
> Thanks. Dmitry.
>
>

Hey Dmitry,

Having worked on callable prototypes I'd say unifying PHP types in Zend
is something we urgently need for PHP to continue evolving.

I'm not sure if PHP have ever been compatible with less-than-32bit
archs but if it was I think it should be said that this would break
such compatibility though.

It would be great if there were some comment in the code near zend_type
declaration where you'd explain how it is used and how additional
data is being added to the pointer.

Is there any use of ZEND_TYPE_CE() macro? It seems to be forgotten there?

If I understood this correctly, the layout of zend_type is as follows:

   [xxxx xxxx xxxx xxxx] xxxx xxxx xxxx xxy0 - for IS_OBJECT type hint
     where the `xxxx`s are a (zend_string *) pointer and `y` designates
     an allow_null flag

   [xxxx xxxx xxxx xxxx] xxxx xxxx xxxx xxy1 - for all other type hints
     where the `xxxx`s are a IS_CALLABLE, _IS_BOOL, IS_LONG, IS_DOUBLE,
     IS_STRING or IS_ARRAY

Do we decide here that IS_REF modifier should belong to the concrete
usages of the type (e.g. referentiality is a property of a variable
and not of a type)?
I'm not sure this if is a right decision or not but I feel like this
question should be raised. It is usually the opposite in other languages.

How would you plan to extend this further? Let's say at some point we
will have callable prototypes or generic classes: we will need to encode
somehow this type into zend_type: `callable(A)` or `A<Foo>`.
Even right now it might be useful (as you suggest with ZEND_TYPE_CE)
to store a (zend_class_entry *) instead of (zend_string *) when
it is known to us in the zend_type.
Seems like without extending zend_type to the size of two pointers
it almost isn't doable :\
Or, it could be made that zend_type, when it's not a simple type hint,
would point to the `zend_type_complex` which would store a
zend_class_entry pointer (or not, if it's for callable) and an array
of type specifiers. But that introduces another indirection.

Anyway thanks for polishing this part, we definitely need zend_type in  
some form.