On Jan 11, 2017 4:36 PM, Nikita Nefedov <inefe...@gmail.com> wrote: 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 can't bu built as 16-bit app :) 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. I'll add something. Is there any use of ZEND_TYPE_CE() macro? It seems to be forgotten there? It's for Bob's typed properties. 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 Almost corect. If low bit is zero, high bits are used as class type name. It's still possible to use IS_OBJECT, without class name. [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)? Reference is not a real PHP 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 :\ If we decide to imlement generics or other complex types, we will have to change just zend_type, now type information is spread among few fields in different structures. 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 might keep a poiner to point to type descriptor, or be converted to structure with embeded fields. Anyway, this is out of scope. Thanks. Dmitry. Anyway thanks for polishing this part, we definitely need zend_type in some form.
