Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89923
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.54 as permitted sender)
MIME-Version: 1.0
Sender: tomac120@gmail.com
In-Reply-To: <CAGTDVF5vbapnCDhJ-RRZo3rUd8LCh1zRcr0xfiAHf2JZMu2O_g@mail.gmail.com>
References: <CAGTDVF5vbapnCDhJ-RRZo3rUd8LCh1zRcr0xfiAHf2JZMu2O_g@mail.gmail.com>
Date: Tue, 29 Dec 2015 18:51:47 -0500
Message-ID: <CAGTDVF7kSgR50hCj-KbDpKkB9uBrLLuEzQP4_Sc7ptEHe8PgNw@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=001a113e23cac8d6240528121a91
Subject: Re: Possible solution to implement type checking hints on stack variables
From: ejrx7753@gmail.com (Elijah Johnson)

--001a113e23cac8d6240528121a91
Content-Type: text/plain; charset=UTF-8

Hi (again),

On Tue, Dec 29, 2015 at 6:48 PM, Elijah Johnson <ejrx7753@gmail.com> wrote:

> 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.
>

This thread is totally ruined because some mail client automatically cut
the threads. No one can easily browse back to see what we discussed and
agreed on. We will have to reformat our idea completely.

--001a113e23cac8d6240528121a91--