Some additional observations -
On Mon, Dec 28, 2015 at 10:03 AM, Elijah Johnson <ejrx7...@gmail.com> wrote:
> Thanks,
>
> On Mon, Dec 28, 2015 at 6:34 AM, François Laupretre <franc...@php.net>
> wrote:
>
>> Hi,
>>
>> Le 26/12/2015 21:35, Elijah Johnson a écrit :
>>
>>> 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 source
>>> 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 with
>> 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çois
>>
>
> 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 = ...; then potentially the same.
On assignment would look something like this (pseudo-code):
bool checkType(zVal, newZVal)
{
bool throw_error = false;
if (MODE_STACK_TYPE_OBJECT)
{
if (isObjectType(zVal))
{
int class_id= GET_PLACEHOLDER_CLASS(zVal);// ie.
zVal.value or value of current object
if (class_id !== GET_CLASS(newZVal))
{
throw_error = true;
}
} else if (IS_OBJECT(newZVal) && !IS_NULL(zVal){
throw_error = true; // assigning an object to a non-null,
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.
