Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97677
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <op.ytwld21ec9evq2@nikita-work-box>
References: <MWHPR02MB24771DF68193D22668A6EE63BF660@MWHPR02MB2477.namprd02.prod.outlook.com>
 <op.ytwld21ec9evq2@nikita-work-box>
Date: Wed, 11 Jan 2017 14:51:22 +0100
Message-ID: <CABdc3WrG03s-ot4uBnMz3sw5pPDtGDgz8Zc3W+mv5Ykc5rcj7A@mail.gmail.com>
To: Nikita Nefedov <inefedor@gmail.com>
Cc: PHP internals list <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=f403045e3b6e689c330545d1e54a
Subject: Re: [PHP-DEV] Change in type-hint representation
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--f403045e3b6e689c330545d1e54a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2017-01-11 14:35 GMT+01:00 Nikita Nefedov <inefedor@gmail.com>:

> 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 jus=
t
>> 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
>
>
I've got prepared Object Typehint RFC
https://wiki.php.net/rfc/object-typehint where
IS_OBJECT is used without class name as type hint for any object kind, if
this 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
would give me
empty zend_string value right? So that won't bive me any chances to store
IS_OBJECT
without classname am I right?



>   [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
>
>


--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--f403045e3b6e689c330545d1e54a--