Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89922
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
Sender: tomac120@gmail.com
Date: Tue, 29 Dec 2015 18:48:21 -0500
Message-ID: <CAGTDVF5vbapnCDhJ-RRZo3rUd8LCh1zRcr0xfiAHf2JZMu2O_g@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0160b7c68609f70528120e65
Subject: Possible solution to implement type checking hints on stack variables
From: ejrx7753@gmail.com (Elijah Johnson)

--089e0160b7c68609f70528120e65
Content-Type: text/plain; charset=UTF-8

Hi (all),

On Mon, Dec 28, 2015 at 6:23 PM, Elijah Johnson <ejrx7753@gmail.com> wrote:

> Hi (all),
>
> On Mon, Dec 28, 2015 at 3:40 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> Hi all,
>>
>> On Tue, Dec 29, 2015 at 5:28 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>> > Object(class) is type, so it makes sense checking class consistency. If
>> we
>> > check object's class, not only the class but also ancestor classes
>> should be
>> > checked. This may affect performance.
>> > I'm not sure if this worth the effort.
>>
>> It sounds negative, so I correct this.
>>
>> Since we have class type hint, it better to support class check. IMO.
>> Almost all cases are simple class equality check. So it wouldn't hurt
>> performance much, I suppose.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohgaki@ohgaki.net
>>
>
> I think that it would be worthwhile to get either a RFC or some test code
> on this, the latter depending on how you would assess the difficulty. The
> feature itself has a huge demand and goes along the lines of current
> development.
>
> If something could be developed, then we could assess performance. I would
> estimate it to be small, however in any case the feature is optional. We're
> not anymore considering to increase the size of the z-val.
>
> The feature has 2 stages, one of which would be drastically easier to
> implement and would show us about performance.
>
> Stage 1 - typing only objects already set by comparing classes upon
> assignment, if set a particular mode
>
> Stage 2 - Adding some form of language hint, which will require a parser
> and some method of storing the class hint for null objects. The latter has
> a proposed solution not sounding hard to implement, but modifying the
> parser sound like a more difficult step.
>

I'm changing the name of this thread. I'm not sure why the original mailer
labeled it "Make strict mode more strict?". This has been a discussion
about extending type hinting to stack variables and resulted in a
possible/plausible solution that we are looking to evaluate.

--089e0160b7c68609f70528120e65--