Re: Re: Change in type-hint representation

Hi Andrea, 1) ZEND_TYPE_CE() is not used yet. We may make distinct between zend_string* and zend_class_entry* based on context or using a value of reserved bit (0x2). 2) We can't initialize zend_strings* in constant structures, so we store const char*. This code converts that const char* into zend_string*. Thanks. Dmitry. ________________________________ From: Andrea Faulds <ajf@ajf.me> Sent: Thursday, January 12, 2017 1:39:56 AM To: internals@lists.php.net Subject: [PHP-DEV] Re: Change in type-hint representation Hey Dmitry, Dmitry Stogov wrote: > 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 I like this proposal, particularly how it's more compact than our existing representation. One comment: it appears that these zend_type values can encode both pointers to strings (class names) and pointers to class entries, right? How do you know whether a given zend_type value is one or the other? Should you just know from context? (It looks like ZEND_TYPE_CE() is in fact unused right now…) On a related note, look at this portion of the diff: + if (ZEND_TYPE_IS_SET(info->type)) { + if (ZEND_TYPE_IS_CLASS(info->type)) { + const char *type_name = (const char*)info->type; Is this a type confusion between zend_string* and const char*? Thanks! -- Andrea Faulds https://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php