> Am 11.01.2017 um 14:35 schrieb Nikita Nefedov <inefe...@gmail.com>: > > On Wed, 11 Jan 2017 15:07:39 +0300, Dmitry Stogov <dmi...@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.
PHP itself uses more than 2^16 bytes of memory… 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: > > [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 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… Bob > 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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
