Morning Dmitry, I know bob has already requested some additions ... nothing to really say about it ...
I just wanted to chime in with VERY NICE :D (shouting intentional) ... Oh and, I think an RFC is pretty pointless ... */me looks forward to master having this* Cheers Joe On Wed, Jan 11, 2017 at 2:00 PM, Niklas Keller <m...@kelunik.com> wrote: > 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 > > >
