2017-01-11 14:35 GMT+01:00 Nikita Nefedov <inefedor@gmail.commailto:inefedor@gmail.com>:
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 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/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?
It should be still possible to use IS_OBJECT without class name.
ZEND_TYPE_ENCODE_HINT(IS_OBJECT, 0)
this even should start working out of the box.
Thanks. Dmitry.
[xxxx xxxx xxxx xxxx] xxxx xxxx xxxx xxy1 - for all other type hints
where the xxxxs 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.
--
--
regards / pozdrawiam,
Michał Brzuchalski
about.me/brzuchalhttp://about.me/brzuchal
brzuchalski.com<https://brzuchalski.com/