Hi François, > > Hi Yasuo,
>> Le 17/09/2015 00:10, Yasuo Ohgaki a écrit : >> Hi all, >> >> Assigning different type to already initialized variable is a bug most >> likely. There may be cases that variable should have several types, >> e.g. return INT for success and FALSE for failure, but programmers can >> use different variable or return value directly or make BOOL/NULL >> exception. > While I don't like the idea of 'auto-typing' a variable (assign it an immutable type depending on the first assignment), the idea is quite similar to one I proposed when we were discussing scalar type hinting : the possibility to assign a type hint to every variable/property. In order to be really usable, it requires compound types but that's a detail because, anyway, we will need compound types. > The problem is that, AFAIK, it implies a mechanism to attach an optional > type hint to a zval, and check it each time a value is assigned. While > this would be extremely powerful and could dramatically change the way > PHP types are considered and handled, this is a huge and complex work, > especially in terms of performance. IMO, this may be an idea for 8.0, > not before. Anyway, I may be wrong, if you see a simpler way to > implement your concept, I'm interested. > Regards > François 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. I'm not familiar enough with the code base, but I imagine that there is one primary location where variables are assigned. Maybe a very small finite number of other cases, such as list() and references. It is possible that a c-function or extension could modify the variable assigned to it, thereby adding a multitude of possible locations. Yet I don't see that this is the case in any standard c implementations. For example, php_array_walk taking a reference, should sort the array in place and in any case not change the value-type. As to adding an additional member to the zval struct, that could be done with a simple bool value. The type of the object could be set inside of the value struct. I believe that this is why Yasuo suggested that the first set value should be chosen. I also disagree with the idea of first-init value as being unclear. If I am not mistaken, with an additional zend_uchar ie. IS_NULL_TYPEDEF = "t" the value member union of zval could contain the identifier of this class. Then update IS_NULL to return true also if "t". I am not qualified to say if that is possible or do it, but it sounds like a "finite" amount of work. I don't see a particularly large performance impact on the language. We have an additional 1 byte per zval and some type checks. Admittedly, the function needs to go a few levels deep in the struct to get the type of an object (when already defined), but performance-wise it should be minor. In the case of setting a null value to an object/string or setting any value to a basic type, I would imagine the impact to extremely small.
