Hi!
> Based on the no reasons that people presented, and some back-of-envelope math.
That is not "knowing", much less "**knowing**". That is a guess based on
an estimate and set of assumptions, some of which very well may be wrong
(such as, people can have more than one reason to vote no).
> The reason is, with strict typing you only need to deal with 8
> possible states for every variable (int, float, bool, resource, array,
> object, callable, null and string). And many of those states you can
> eliminate based on context (you know an argument passed to an int
> declared parameter will always be an int).
This is possible with coercive typing too, if the argument is declared
int then it will be coerced to int.
> Without strict typing, you also need to consider virtual states:
> castable object (internally implementing get()), stringable object
> (implementing __tostring), numeric string ("123"), kind-of numeric
> string ("123 abc"), etc. And many of those states *can't* be
> eliminated based on context.
I don't see why you don't need to consider them anyway - if your
analyzer cares about ability of the object to be casted to a string,
you'd have to carry this information anyway - for use in (string), echo,
"$foo", internal functions, etc. So again no advantage here.
> An example is that ($a + $b) we know can never produce a string. We
> know it can never produce a bool, resource, array, callable or null.
> The only things it can produce is an object, an int or a float. So if
> we see expressions of the form `$c = ($a + $b)`, we can immediately
> deduce something about $c and therefore reduce the number of possible
> states.
This is right, but no advantage to strict typing here, this is true
under any typing model.
> With strict typing, if we then pass $c to a function expecting int, we
> know that C must be an int. Which means that $a and $b therefore
That seems to be an incorrect assumption - passing something to function
asking for an int doesn't mean it is an int. It means that inside
function it would be int or fail happens, but that is achieved with
coercive typing too, so no advantage to strict typing here. Of course,
since we already know $c is an int or a float or an object, no
additional information here is obtained, and we do not know anything
about $c itself - we only know the "A->B" is true but we don't know
whether A is true and thus not whether B is true.
> **must** be castable to an integer (otherwise an error will be thrown
> down the road). So we've just reduced $a down to 5 types: int, numeric
> string, null, bool and castable object (from at least 12). And $b the
Yes, after the expression is done and *if* it did not error out, we can
deduce some things about $a's value *after* the expression. But we have
no guarantees the expression would succeed and no advantage to string
typing which does not come into play here at all.
> same. So our expression has 10 possible valid (non-error-case)
> permutations. Down from the approximately 432 possibilities before
> hand (12 for $a, 12 for $b, 3 for $c). And that's with unknown $a and
> unknown $b.
Still don't see any advantage to strict typing here. Deduction about the
behavior of + can be made without any strict typing involved, as far as
I can see.
> With strictly typed $a and $b, the expression drops to 1 possible
> permutation. And you can detect if it's a valid one. And many static
> analysis engines do this.
I didn't see any proposal that proposes strictly types variables. As for
parameters, both strict and coercive typing provide knowledge about the
types of parameter inside the function they are defined in, so no
advantage to strict typing here.
> It's not that static analysis is impossible without strict typing.
> It's that it gets drastically easier. Both in terms of processing
It may be so, but yet again it was not demonstrated.
> Does that substantiate the claim? If not, I'm definitely open to
> discussing it further.
So far I did not see any substantiation, unless I have not understood
what your analyzer is doing.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
