2017-01-11 14:35 GMT+01:00 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. > > 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 > > -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com
