Michał Brzuchalski <mic...@brzuchalski.com> schrieb am Mi., 11. Jan. 2017, 14:51:
> 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? > Morning. As far as I understand it, 0 just means no built in type. As long as no class name is there, it's just no type at all. Regards, Niklas > [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 >
