> -----Original Message-----
> From: Jefferson González [mailto:jgm...@gmail.com]
> Sent: Sunday, February 22, 2015 11:59 PM
> To: Stanislav Malyshev
> Cc: Etienne Kneuss; Anthony Ferrara; Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> 2015-02-22 16:38 GMT-04:00 Stanislav Malyshev <smalys...@gmail.com>:
>
>
> Yes, that's not the case, at least nobody ever showed that to be the
> case. In general, as JS example (among many others) shows, it is
> completely possible to have JIT without strict typing. In particular,
> coercive typing provides as much information as strict typing about
> variable type after passing the function boundary - the only
> difference
> is what happens _at_ the boundary and how the engine behaves
> when the
> types do not match, but I do not see where big performance
> difference
> would come from - the only possibility for different behavior would
> be
> if your app requires constant type juggling (checks are needed in
> strict
> mode anyway, since variables are not typed) - but in this case in strict
> mode you'd have to do manual type conversions, which aren't in any
> way
> faster than engine type conversions.
> So the case for JIT being somehow better with strict typing so far
> remains a myth without any substantiation.
>
>
>
>
> Well, strict on a JIT environment may haven't been proved, but it surely
> has
> been proved on statically compiled languages like C.
Jefferson,
Strict type hints will not make PHP even remotely similar or otherwise
comparable to a statically typed language like C. It will take totally
different facilities being added to PHP, which are not being considered.
Currently, a JIT in the
> most cases can't compete to the bare performance of a static compiled
> language, both in resources and CPU, so how is non strict better in that
> sense?
Nobody is saying it's better in that sense. Nobody is also suggesting that
a statically compiled language like C isn't a lot easier to optimize than a
dynamic language with JIT. What we are saying is that Strict type hints are
of no help making JIT any better or easier, compared to Dynamic/Coercive
hints. I provided what I believe to be detailed proof for that in my email
titled 'JIT'.
> I thought those checks could be optional if generated at call time, thats
> why I
> gave these 2 examples:
>
> calc(1, 5) -> no need for type checking or conversion, do a direct call
> calc("12", "15") -> calc(strToInt(value1), strToInt(value2)) calc($var1,
> $var2) -
> > needs type checking and conversion if required
That's the wrong comparison to make. We should be comparing the same calls
with the two systems, rather than one call in one system and a different one
in a different system.
Taking your example:
calc(1, 5) -> no need for type checking or conversion *in neither Strict
type hints nor Coercive/Dynamic type hints*, do a direct call. Identical
performance.
calc("1", "5") -> fails in strict type hints, succeeds in Dynamic/Coercive
type hints (cannot be optimized)
Again, this illustrates that the difference between the two is that of
*functionality*, not performance.
If you're saying that calc("1", "5") is slower than calc(1, 5) when using
dynamic type hints - then that would be correct, but also pretty meaningless
from a performance standpoint, if what you have are string values. And if
you have integer values, well then, we've already established there's no
difference between the two type hinting systems.
Typically, you obtain the data you need in a type that's not under your
control. You're getting data from the browser, database, filesystem, web
service or some algorithm - the type of the values you get is determined by
the API functions you're using to get the data from.
So what are your options if what you have in your hand is "1" and "5",
because that's how the APIs provided the data to you, as opposed to 1 and 5?
Before they can be added, they need to be converted to integer format,
whether this is done by explicitly casting them (likely outcome in case of a
strict type hint), casting them through a safe coercive STH, or letting
PHP's + operator implementation do it for you. The data needs to be
converted somewhere.
> So what you are saying is that there is no way of determining the type of
> a
> variable (only at runtime), as Zeev explained on the previous messages,
> since
> variables aren't typed, checks are mandatory either way.
There are ways to infer typing information both during compile time and also
create 'educated guess' as to what the data type is going to be based on
runtime information, but:
1. No, it's absolutely not possible to always determine the type of
variables during compile-time, you'd often (perhaps more often than not)
only know the data type with absolute certainty only at runtime
2. Whatever you CAN infer, you can infer equally regardless of whether a
piece of code uses strict type hints or dynamic ones.
> Please provide a substantiation for this opinion. So far what was
> provided was not correct.
>
>
>
> Static typed languages -> Direct conversion to machine code
>
> Dynamic typed languages with JIT -> Intermediate representation ->
> Checks -
> > Conversion to machine code with checks.
True statements (more or less) but irrelevant to the discussion. Strict
type hints do not make PHP in any way even remotely similar to a statically
typed language. I don't believe Anthony, Joe or anybody are claiming
otherwise.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
