Zeev,
I won't nit-pick every point, but there are a few I think need to be clarified.
>> > Proponents of Dynamic STH bring up consistency with the rest of the
>> language, including some fundamental type-juggling aspects that have been
>> key tenets of PHP since its inception. Strict STH, in their view, is
>> inconsistent
>> with these tenets.
>>
>> Dynamic STH is apparently consistency with the rest of the language's
>> treatment of scalar types. It's inconsistent with the rest of the
>> languages
>> treatment of parameters.
>
> Not in the way Andrea proposed it, IIRC. She opted to go for consistency
> with internal functions. Either way, at the risk of being shot for talking
> about spiritual things, Dynamic STH is consistent with the dynamic spirit of
> PHP, even if there are some discrepancies between its rule-set and the
> implicit typing rules that govern expressions. Note that in this RFC I'm
> actually suggesting a possible way forward that will align *all* aspects of
> PHP, including implicit casting - and have them all governed by a single set
> of rules.
The point I was making up to there is that we currently have 2 type
systems: user-land object and ZPP-scalar. So in any given function you
have 2 type systems interacting. The current ZPP scalar type is
dynamic, and user-land object static.
With the proposal here, you'd unify user-land scalar to behave as
zpp-scalar. So you'd have two type systems in any given function:
scalar and object (which behave differently).
My proposal gives you the same two by default (scalar and object) and
a strict switch to collapse them into a single, unified type system.
This is even more apparent with the int-float acceptance, because we
can mentally model Float as an object that extends Int. Then it makes
perfect sense why you'd accept ints where you see floats, but not the
opposite.
>> However there's an important point to make here: a lot of best practice
>> has
>> been pushing against the way PHP treats scalar types in certain cases.
>> Specifically around == vs === and using strict comparison mode in
>> in_array,
>> etc.
>
> I think you're correct on comparisons, but not so much on the rest. Dynamic
> use of scalars in expressions is still exceptionally common in PHP code.
> Even with comparisons, == is still very common - and you'd use == vs. ===
> depending on what you need.
>
>> So while it appears consistent with the rest of PHP, it only does so if
>> you
>> ignore a large part of both the language and the way it's commonly used.
>
> Let's agree to disagree. That's one thing we can always agree on! :)
I'm talking about the object system. I don't think you're disagreeing
that it's static. Hence coercive scalars are consistent only if you
look at 1/2 the type system. That was the point I was making there.
>> 3. "Just Do It but give users an option to not" - This has the problems
>> that
>> E_DEPRECATED has, but it also gets us back to having fundamental code
>> behavior controlled by an INI setting, which for a very long time this
>> community has generally seen as a bad thing (especially for portability
>> and
>> code re-use).
>
> I do too, and I was upfront about their cons, not just pros. And yet, they
> all bring us to a much better outcome within a relatively short period of
> time (in the lifetime of a language) than the Dual Mode will.
Let's agree to disagree that an ini setting will be better than a
per-file setting.
In fact, I personally think this is major enough of an issue that I
will vote no simply on this reason alone (type behavior depending on
an ini setting in any way shape or form).
>> > Further, the two sets can cause the same functions to behave
>> > differently depending on where they're being called
>>
>> I think that's misleading. The functions will always behave the same.
>> The difference is how you get data into the function. The behavior
>> difference
>> is in your code, not the end function.
>
> I'll be happy to get a suggestion from you on how to reword that.
> Ultimately, from the layman user's point of view, she'd be calling foo()
> from one place and have it accept her arguments, and foo() from another
> place and have it reject the very same arguments.
Let me think on it and I will come up with something.
>> With strict mode, you'd have to embed a cast (smart or explicit) to
>> convert to
>> an integer at the point the data comes in.
>
> First, I'm not aware of smart/safe casts being available or proposed at this
> point.
> Secondly, why at the point the data comes in? That would be ideal for
> static analyzers, but it's probably a lot more common that it will be done
> at the first point in time where it gets rejected.
By "smart cast" I was referring to a function which checked
is_numeric(). Not a new language construct.
> I have a hard time connecting to the 'power' approach. I think developers
> want their code to work, with minimal effort, and be secure. Coercive
> scalar type hints will do an excellent job at that. Strict type hints will
> be more work, are bound to a lot of trigger "Oh come on" responses, and as a
> special bonus - proliferate the use of explicit casts. Let me top that -
> you'd have developers who think they're security conscious, because they're
> using strict mode - with code that's full of explicit casts.
I agree we should have users avoid explicit casts. That's why the
dual-mode proposal exists. If users don't want to control their types,
they should use the default mode. And everything works fine.
If they know what they want, then the explicit cast becomes a
documenting piece of information that "this is supposed to happen".
Ex:
function takesInt(int $a) {}
function foo(float $b) {
return takesInt($b);
}
In weak mode, that "just works". But is it supposed to just work? You
have no idea. The next developer who comes will look at it and ask "is
that supposed to truncate, or was that an oversight?" and have no
idea. But in strict mode, placing an explicit cast before $b shows the
next developer who comes there "the truncation was intentional".
>> > Static Analysis. It is the position of several Strict STH proponents
>> > that Strict STH can help static analysis in certain cases. For the
>> > same reasons mentioned above about JIT, we don't believe that is the
>> > case
>>
>> This is patently false.
>
> It's actually patently true. We don't believe that is the case. QED.
To understand why "we don't believe" can be false, let's make an
analogy: I can say that I don't believe in gravity. That doesn't mean
that the opinion isn't patently false just because it was stated as an
opinion (or rather the "believe" is true, but the implication of the
belief is false)...
>
>> Keep not believing it all you want, but *static analysis*
>> requires statically looking at code. Which means you have no value
>> information. So static analysis can't possibly happen in cases where you
>> need
>> to know about value information (because it's not there). Yes, at function
>> entry you know the types. But static analysis isn't about analyzing a
>> single
>> function (in fact, that's the least interesting case). It's more about
>> analyzing a
>> series of functions, a function call graph. And in that case strict typing
>> (based
>> only on
>> type) does make a big difference.
>
> I think it's fair to say that while we were unable to convince you there's
> no tangible extra value in Strict STH compared to any other kind of STH that
> guarantees the type of value a function will get, you were also unable to
> convince Dmitry, Stas or myself - all of which independently discussed it
> with you. Again, despite that, I'm not saying that you're "patently wrong",
> just that I don't believe you're right.
I've built a static analyzer that's public. I've talked to people who
build them for a living. I don't claim to be an expert in them (far
from it), but what I've seen and learned is that what you're talking
about here either isn't possible (yet) or is difficult enough to be
impractical (in terms of computing resources necessary).
You can disagree with me all you want. You don't even need to convince
me. All you need to do is disprove me. Show me a static analyzer for a
sufficiently dynamic language (Scalar PHP or full JS - not ASM.js -
would work) and I'll happy apologize and retract the comment. But so
far all I've seen are people saying it's possible even in presence of
arguments to the contrary (why it's not possible).
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
