Flexible type hinting

Also, looking at the patch I think it doesn't cover the matter of inheriting
the typehinted methods - i.e. if there's a typehinted method, could I
override it with non-typehinted version or vice versa? What about typehinted
interfaces?

I don't think we need to worry about this. Consider it to be the same
as default values. So yes, yes, allowed but dont do anything since
those functions are never called.

Paul

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

--

--
Paul Biggar
paul.biggar@gmail.com

I'm an advocate for introducing optional type hinting as I write many
assert('is_*($foo)') a day.

And there's only two ways to do it - either make absolutely all functions
and variables that interact with typehinted functions to be strict-typed
(which we don't plan do) or do casts on each call to hinted function. I do
not see how anything else could produce robust code provided that type
mismatch is a fatal error and variables can not carry type.

In an application not all layers have to deal with arbitrary parameters,
only the layer with user input does. Do I write a (Traversable) cast before
passing an object to foreach()? No, because the object is not user input. My
application will parse POST, GET, COOKIE parameters in layer 1 and call the
underlying layer 2 with the right data type; down from the layer 2 to 4, 5,
10 layer I can use type hinting.
Type hints became part of the contract of layer N: if there is a runtime
error the problem is in layer N-1 not respecting the contract.
function generate_numbers(int $maximum)
{
return .....
}
function presentation_layer_display_numbers($input) {
if (isset($input['max']) and is_numeric($input['max'])) {
foreach (generate_numbers($input['max']) as $i) {
echo "<p>$i</p>";
}
} else {
echo $formCodeWithHighlightedErrors;
}
}
presentation_layer_display_numbers($_POST);
Validating input it's something we should already do, but the other parts of
the code can use type hinting. If I really pass a type that is not right to
generate_numbers(), it will be a very bad thing because the function will
not know how to recover; and it should not do: it's a job for the top layer.

Also, looking at the patch I think it doesn't cover the matter of inheriting

the typehinted methods - i.e. if there's a typehinted method, could I
override it with non-typehinted version or vice versa? What about typehinted
interfaces?

For the Liskov Substitution Principle if B extends A you should be able to
call B as if it were A. So typehinted methods should be overriden respecting
the typehint to allow polymorphism.
interface Calculator
{
public function sum(int $a, int $b);
}
class ScientificCalculator
{
public function sum(int $a, int $b);
}
class BrokenCalculator
{
public function sum(int $a, string $b); // some error is thrown
}
class AnotherBrokenCalculator
{
public function sum(int $a, $b); // some error is thrown
}

--
Giorgio Sironi
Piccolo Principe & Ossigeno Scripter
http://ossigeno.sourceforge.net

Hi!

2. Type hinting will not create a mess of cast to the right types
   in the code as Stas had suggested, in close to a million lines of
   PHP code we have, I've been able to find less then 1000 (just did a
   grep) instances of casts. There is a good reason for that once you
   get out of the input processing stage you typically (aside from
   __toString()) have the data in the right type. The code also
   includes bits from PEAR and external

The problem here is that if you want to write a robust code that
wouldn't randomly fail at runtime "typically" isn't good enough

If it fails it means some funciton did not return the expected value
and that's a problem, not something that should be ignored if you
decided (if you don't want to use, then things remain as they are) to
use type hinting.

• since wrong type is supposed to be a fatal error (which one could
  not handle in the typehinted library code since it happens on the
  client side before your code takes control), you would want to
  ensure that would never happen when you call a typedhinted function.
  And there's only two ways to do it - either make absolutely all
  functions and variables that interact with typehinted functions to
  be strict-typed (which we don't plan do) or do casts on each call to
  hinted function. I do not see how anything else could produce robust
  code provided that type mismatch is a fatal error and variables can
  not carry type.

"stock php" for people to use. But please, don't reject this idea
because you personally don't see yourself using it or because you
want

Being a C programmer for... hmm... about 20 years now I think I
don't have too much problem with strictly typed languages :) I just
think doing it in PHP the way you want to do it is going to produce
a lot of issues that people tend to under-appreciate when they cheer
the new cool feature.

Also, looking at the patch I think it doesn't cover the matter of
inheriting the typehinted methods - i.e. if there's a typehinted
method, could I override it with non-typehinted version or vice
versa? What about typehinted interfaces?

Which is fine, because some people can use that functionality to
overload methods they don't want to be type hinted from external libs
the may be using.

to work in a future with a library/framework that is strict about
its input
or some far fetched idea that it will change the very nature of PHP.

I don't think we are worried about it changing PHP, or about libraries
using strict type hints. We are worried that libraries will use no
hints, because the ones on offer are not useful to them.

I think he is replying to me here. I am worried that with Ilia's
proposal, people will strictly type everything, even where weakly
typed would suffice. The reason being that developers are lazy. With
these type "hints" (they are not actually hints, but "checks" as you
already made clear), they can very easily move the burden of type
juggeling explicitly to the user of their code.

At least in my world, I use a lot of 3rd party libraries, which will
then likely become essentially strictly typed. While strictly typing
can prevent bugs and all sorts of good stuff, we should be more
hesitant when it comes to giving people tools that make it easy
(encourage) to turn a core principle of PHP upside down.

I know that "numeric" was a concession to people with my concern from
the last discussion. But it doesnt cover all the bases of types. In
that vain Paul's proposal does indeed provide a syntax that at least
enables both approaches. More importantly it proposes a syntax that
requires the same number of characters for both approaches. You might
laugh at this comment, but I believe that the overuse of "private"
that I am seeing has a lot to do with the fact that its shorter than
"protected".

I have not really made up my mind about Paul's proposal, but I just
wanted to make the above points.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

1. Strict type hinting helps to solve bugs, both the ones made out of
   careless/missing validation as well as subtle logic bugs that often
   take
   hours to resolve. I can tell you that within a week of implementing
   type
   hints we've been able to identify 30-40 bugs within a period of
   day. Many of
   which would not have been detected with "flexible" type hints that
   Paul is
   suggesting here is one example:

I think you might not have read what I suggested (it is different than
the one I emailed to you privately). What you want is fully supported.
If you must be passed an int, use the +int hint.

I'd rather use -int, then +int and make people who want loose typing
do the extra bit, because native typing should be strict.

Hi Lukas,

hmm not sure that the consensus of a "weak" check would be an automatic
cast. Actually that wouldnt be much of a check in that case. I think the
other side is more asking for what Ilia already begun with "numeric" in the
sense of a weak checker. After the check it could go ahead and cast too for
all I care, but it shouldnt be the equivalent of a cast. But maybe you are
not implying that and I am just getting confused by the syntax.

I think people wanted an automatic cast for the weak check. The idea
would be that if you hinted "(int)", you could be guaranteed that you
got an int. The syntax was suggested (I believe, it wasn't my
suggestion) to look like casting.

Thanks,
Paul

--
Paul Biggar
paul.biggar@gmail.com