Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97680
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.217 cause and error)
MIME-Version: 1.0
References: <MWHPR02MB24771DF68193D22668A6EE63BF660@MWHPR02MB2477.namprd02.prod.outlook.com>
 <op.ytwld21ec9evq2@nikita-work-box> <CABdc3WrG03s-ot4uBnMz3sw5pPDtGDgz8Zc3W+mv5Ykc5rcj7A@mail.gmail.com>
In-Reply-To: <CABdc3WrG03s-ot4uBnMz3sw5pPDtGDgz8Zc3W+mv5Ykc5rcj7A@mail.gmail.com>
Date: Wed, 11 Jan 2017 14:00:02 +0000
Message-ID: <CANUQDCjyEgd=D0prH-yMS8DO6D=UjUut-1YZKLvROduUF24XXQ@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>, 
	Nikita Nefedov <inefedor@gmail.com>
Cc: Dmitry Stogov <dmitry@zend.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c05f792fe53f30545d204b9
Subject: Re: [PHP-DEV] Change in type-hint representation
From: me@kelunik.com (Niklas Keller)

--94eb2c05f792fe53f30545d204b9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Micha=C5=82 Brzuchalski <michal@brzuchalski.com> schrieb am Mi., 11. Jan. 2=
017,
14:51:

> 2017-01-11 14:35 GMT+01:00 Nikita Nefedov <inefedor@gmail.com>:
>
> > On Wed, 11 Jan 2017 15:07:39 +0300, Dmitry Stogov <dmitry@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 tha=
t
> >> 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 wo=
rk
> >> 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 ther=
e?
> >
> > 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 language=
s.
> >
> > 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 encod=
e
> > 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=C5=82 Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>

--94eb2c05f792fe53f30545d204b9--