Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97681
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.116.26 as permitted sender)
Message-ID: <BLU436-SMTP552B1405736E37BB5FB01BE2660@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
In-Reply-To: <op.ytwld21ec9evq2@nikita-work-box>
Date: Wed, 11 Jan 2017 15:09:25 +0100
CC: PHP internals list <internals@lists.php.net>,
 Dmitry Stogov <dmitry@zend.com>
Content-Transfer-Encoding: quoted-printable
References: <MWHPR02MB24771DF68193D22668A6EE63BF660@MWHPR02MB2477.namprd02.prod.outlook.com>
 <op.ytwld21ec9evq2@nikita-work-box>
To: Nikita Nefedov <inefedor@gmail.com>
Subject: Re: [PHP-DEV] Change in type-hint representation
From: bobwei9@hotmail.com (Bob Weinand)


> Am 11.01.2017 um 14:35 schrieb Nikita Nefedov <inefedor@gmail.com>:
>=20
> On Wed, 11 Jan 2017 15:07:39 +0300, Dmitry Stogov <dmitry@zend.com> =
wrote:
>=20
>> Hi,
>>=20
>>=20
>> I propose to introduce a unified type representation (zend_type).
>>=20
>> Now it's going to be used for typing of arguments and return values.
>>=20
>> Later we should use it for properties and other things.
>>=20
>>=20
>> https://gist.github.com/dstogov/1b25079856afccf0d69f77d499cb0ab1
>>=20
>>=20
>> The main changes are in zend_types.h and zend_compile.h, the rest is =
just an adoption for new type representation.
>>=20
>> I don't think we need RFC, because this is just an internal change =
that doesn't change behavior.
>>=20
>>=20
>> I got the idea working on typed properties together with Bob and Joe.
>>=20
>> =
https://github.com/php/php-src/compare/master...bwoebi:typed_ref_propertie=
s
>>=20
>> I think it would be better to introduce zend_type and then continue =
work on typed properties.
>>=20
>>=20
>> Any comments?
>>=20
>>=20
>> Thanks. Dmitry.
>>=20
>>=20
>=20
> Hey Dmitry,
>=20
> Having worked on callable prototypes I'd say unifying PHP types in =
Zend
> is something we urgently need for PHP to continue evolving.
>=20
> 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.

PHP itself uses more than 2^16 bytes of memory=E2=80=A6 And we anyway =
have some code assuming that sizeof(void *) is a power of two. Hence =
we'll anyway need at least 32 bit.

> 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.

That's what the ZEND_TYPE_ENCODE_*() macros are for?

> Is there any use of ZEND_TYPE_CE() macro? It seems to be forgotten =
there?

Not necessarily in this patch, but in typed_ref_property branch =
reference types use the CE directly.

> If I understood this correctly, the layout of zend_type is as follows:
>=20
>  [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
>=20
>  [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

correct.

> 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.

We nowhere user-facing consider references to be a separate type, just =
internally for the zval representation (which was is_ref in PHP 5) - and =
as such being a reference is a property of the variable.

> 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.

zend_type is just a typedef. If needed in future we may define it to =
occupy 2 * sizeof(void *) or such, just as we'll need it.
The goal of the patch is making type encoding transparent and handleable =
in a single place.
The current way of adding a new class of types usually was adding a new =
element to the relevant structs or similar hacks=E2=80=A6

Bob

> Anyway thanks for polishing this part, we definitely need zend_type in =
some form.
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>=20