Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 104.47.32.129 as permitted sender)
To: =?iso-8859-2?Q?Micha=B3_Brzuchalski?= <michal@brzuchalski.com>
CC: Dmitry Stogov <dmitry@zend.com>, PHP internals list
	<internals@lists.php.net>, Nikita Nefedov <inefedor@gmail.com>
Thread-Topic: [PHP-DEV] Change in type-hint representation
Thread-Index: AQHSbBcuJH94e0ZZMkmDI5OUmOzW+w==
Date: Wed, 11 Jan 2017 14:32:54 +0000
Message-ID: <MWHPR02MB2477D2804A1F04F6D37E5E36BF660@MWHPR02MB2477.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_MWHPR02MB2477D2804A1F04F6D37E5E36BF660MWHPR02MB2477namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 14:32:54.7709
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2479
Subject: Re: [PHP-DEV] Change in type-hint representation
From: dmitry@zend.com (Dmitry Stogov)

--_000_MWHPR02MB2477D2804A1F04F6D37E5E36BF660MWHPR02MB2477namp_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable



On Jan 11, 2017 4:51 PM, Micha=B3 Brzuchalski <michal@brzuchalski.com> wrot=
e:


2017-01-11 14:35 GMT+01:00 Nikita Nefedov <inefedor@gmail.com<mailto:inefed=
or@gmail.com>>:
On Wed, 11 Jan 2017 15:07:39 +0300, Dmitry Stogov <dmitry@zend.com<mailto:d=
mitry@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 a=
n adoption for new type representation.

I don't think we need RFC, because this is just an internal change that doe=
sn'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


I've got prepared Object Typehint RFC https://wiki.php.net/rfc/object-typeh=
int where
IS_OBJECT is used without class name as type hint for any object kind, if t=
his patch
would be applied how can I deal with this new zend_type?
As far as I undestand last 0 for IS_OBJECT and no (zend_string *) pointer w=
ould give me
empty zend_string value right? So that won't bive me any chances to store I=
S_OBJECT
without classname am I right?

It should be still possible to use IS_OBJECT without class name.

ZEND_TYPE_ENCODE_HINT(IS_OBJECT, 0)

this even should start working out of the box.

Thanks. Dmitry.



  [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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php




--
regards / pozdrawiam,
--
Micha=B3 Brzuchalski
about.me/brzuchal<http://about.me/brzuchal>
brzuchalski.com<https://brzuchalski.com/>


--_000_MWHPR02MB2477D2804A1F04F6D37E5E36BF660MWHPR02MB2477namp_--