Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89910
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
Sender: tomac120@gmail.com
In-Reply-To: <CAGTDVF5RAxkExV2WDfBdeNb5x+5+aQDYkSAn+2wRkbxKyYVoBw@mail.gmail.com>
References: <CANmB6N8de7Hrs0VZOYoy9tSq9Jh7TvheBKX--qhLoc5Jf562wQ@mail.gmail.com>
	<56811E49.1040106@php.net>
	<CAGTDVF5RAxkExV2WDfBdeNb5x+5+aQDYkSAn+2wRkbxKyYVoBw@mail.gmail.com>
Date: Mon, 28 Dec 2015 10:47:34 -0500
Message-ID: <CAGTDVF6Pbq3vKcoHu+cSPB9k-L=G_wCRAxBCBBHF_A2CPNkWjw@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=089e0160b7c6489e190527f73937
Subject: Re: [PHP-DEV] Make strict mode more strict?
From: ejrx7753@gmail.com (Elijah Johnson)

--089e0160b7c6489e190527f73937
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Some additional observations -

On Mon, Dec 28, 2015 at 10:03 AM, Elijah Johnson <ejrx7753@gmail.com> wrote=
:

> Thanks,
>
> On Mon, Dec 28, 2015 at 6:34 AM, Fran=C3=A7ois Laupretre <francois@php.ne=
t>
> wrote:
>
>> Hi,
>>
>> Le 26/12/2015 21:35, Elijah Johnson a =C3=A9crit :
>>
>>> Can you explain your statement that this would be a huge and complex
>>> work? You must mean that there would be multiple places in the php sour=
ce
>>> code where variables are assigned? I'm not yet discussing performance, =
but
>>> only the aspect of adding the feature.
>>>
>>
>> There may other options I don't know but, AFAIK, this implies adding an
>> optional type hint at the zval level. This type hint should be verified =
at
>> least before each conversion.  Copy-on-write is an other issue, as it is
>> currently not compatible with zval type hints. Seeing only variables wit=
h
>> well-defined names, and focusing on arrays, only scratches the surface.
>> Everything happens at the zval level. So, IMO, attaching type hints to
>> variables and properties is a huge and complex work.
>>
>> Regards
>>
>> Fran=C3=A7ois
>>
>
> I think I see what you are saying. Copy on write takes a reference to the
> entire z-val in two local variables, so a type-hint at the z-val level
> would be shared.
>
> This returns us to the insight of the original mailer who suggested that
> an object or array variable should be typed by its first-assigned object.
> This would simply need to be a global mode - stack-mode-legacy,
> stack-mode-static-object-types, and stack-mode-super-strict for those who
> want basic types also.
>
> I'm not saying that this is ideal, just that we need to compromise a bit
> to accommodate our existing code base and performance issues.
>
> The proposal for an additional z-val which stores the class name in the
> zval.value member and is counted as null could accommodate the case where
> the user wants to assign the type before he has an object.
>
> I think this is the best option. Another theory I had was to store the
> types at the context level in some kind of array, but its really too much=
.
>
> The idea just now proposed of 3 global modes will eliminate the issue of
> storing at the z-val level. The mode "stack-mode-static-object-types" is
> even already compatible with every line of code that I have properly
> written in PHP.
>

The mode "stack-mode-static-object-types" would ideally also prevent
assignment of an object with a current string value, or string placeholder
value. What I mean by placeholder value - an additional z-val type "t"
returning true for IS_NULL, where the class name id is stored in value
union. This would be declared by type hint ex. MyObject $object; If the
variable is assigned, MyObject $object =3D ...; then potentially the same.

On assignment would look something like this (pseudo-code):

bool checkType(zVal, newZVal)
{
      bool throw_error =3D false;
     if (MODE_STACK_TYPE_OBJECT)
     {
           if (isObjectType(zVal))
           {
                 int class_id=3D GET_PLACEHOLDER_CLASS(zVal);// ie.
zVal.value or value of current object
                 if (class_id !=3D=3D GET_CLASS(newZVal))
                 {
                       throw_error =3D true;
                }
           } else if (IS_OBJECT(newZVal) && !IS_NULL(zVal){
                  throw_error =3D true; // assigning an object to a non-nul=
l,
non-object
           }
     }
     if (throw_error)
     {
          // assign to null, generate TypeError
         //  ie. Warning: assign of type to type, assigned null value
         return false; // prevent assignment by caller
     }
     return true
}

Some additional checks would likely be necessary to prevent placeholders
from being assigned and returned, and if strict mode was implemented, there
would need to be a second placeholder type (or some other means of
identification such as a constant).

Implementing placeholders isn't a necessary step, but it would make for
very readable code.

--089e0160b7c6489e190527f73937--