Re: Change in type-hint representation

From: Date: Wed, 11 Jan 2017 13:59:25 +0000
Subject: Re: Change in type-hint representation
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-97679@lists.php.net to get a copy of this message
2017-01-11 14:57 GMT+01:00 Nikita Nefedov <inefedor@gmail.com>: > On Wed, 11 Jan 2017 16:51:22 +0300, Michał Brzuchalski < > michal@brzuchalski.com> wrote: > > >> >> 2017-01-11 14:35 GMT+01:00 Nikita Nefedov <inefedor@gmail.com>: >> >>> -- snip -- >>> >>> >>> [xxxx xxxx xxxx xxxx] xxxx xxxx xxxx xxy0 - for IS_OBJECT type hint >>> >>> where the xxxxs are a (zend_string *) pointer and >>> y designates >>> >>> an allow_null flag >>> >>> >>> >> I've got prepared Object Typehint RFC >> https://wiki.php.net/rfc/objec >> t-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? >> > > Hey Michal, > > no for you it's quite easy, you can just store IS_OBJECT with > > ZEND_TYPE_ENCODE_HINT(IS_OBJECT, is_null) > > But then the code that checks ZEND_TYPE_IS_CLASS will need to > be adjusted to work with > > ZEND_TYPE_IS_HINT(type) == 1 && ZEND_TYPE_HINT(type) == IS_OBJECT > Thanks. -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com

« previous php.internals (#97679) next »