[RFC] Strict type hints (parameter and return value)

Hi!

Scalar is useful if you DON'T want an array or object - but don't care
if you get an int/string/whatnot

When you can use string but not object with __toString?

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

I like this alot better too, the only downside is compatibility
problems.

Can you explain, I understand; in partial the problem but I am curious what
can not be solved through added logic?

function int() {
}

PHP won't know if this is a return type hint or function name. This
specific case might be solvable with added logic though, I really don't
know how to do it or how hard it would be; alot of this is done in the
parser which I am only slightly familiar with.

What's the use of such code? If $var is '1' and not 1, what's the use of
throwing an exception and having to handle it later (basically by failing
the task, since you don't know how to do foo() now) - instead of just doing
with that 1 what was intended for? There's no any difference between 1 and
'1' that can be important to anybody. Only difference is the way it is
represented in underlying bits in zvals, about which nobody should ever
care. That's like making function that would accept only arguments that has
3'rd bit of pointer set to 1 and 5th bit set to 0, and reject all others. No
sane application should ever behave this way. Writing such function is just
plain wrong, it replaces the substance of programming with nitpicking over
the details that are not important. Whole phenomenon of dynamic languages
has grown on the principle of liberating people from caring for bits and
concentrate on substance, and now you try to drag the bits back in.
So every time you call foo you need try/catch? And that's supposed to be
good?

Somebody missed the point...

Seeing how you work for zend I thought maybe you have used the zend
framework = ) Sorry in my example I used "int" instead of "numeric", but my
point is the same, grep in zend framework for is_bool.

It does what you are complaining about:

From: Zend_Pdf_Element_Numeric
public function __construct($val)
{
if ( !is_numeric($val) ) {
throw new Zend_Pdf_Exception('Argument must be numeric');
}

    $this->value   = $val;
}

That could be...
public function __construct(numeric $val)
{
$this->value = $val;
}

So, let's re-visit my point of "less code bloat"....

Actually, is_numeric checks for strings that contain numeric values,
it's not the same as is_bool, is_int, is_float, etc, which check the
variable's type.

Your point is very valid for is_int and similar functions, just not
is_numeric(). I just did a grep on zend framework for is_int and there
were tons of results.

Hi!

Seeing how you work for zend I thought maybe you have used the zend
framework = ) Sorry in my example I used "int" instead of "numeric", but
my point is the same, grep in zend framework for is_bool.

It might come as a surprise to you, but I did not write whole Zend
Framework personally :) Moreover, as even more surprise I did not even
inspect personally each line of code. As a final shock, I am not
convinced functions in PHP should throw exceptions when parameters don't
match - and even if they do, first they should attempt to make sense of
parameters (which makes string hints like "integer" and "string" make no
sense - you can convert a lot of things to int or string). Even if they
can't, it's much better to be handled on user code level with error
message that makes sense and way that makes sense for application - but
I could kind of live with the scenario where these hints would work as
internal function types work now. However, that's not what is proposed -
what is proposed is that if you've got int typehint, '1' would be
rejected. Having such restriction makes no sense and goes contrary to
what PHP and dynamic languages in general are.

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

Hi!

as this seems to be your only argument throughout the discussion, I
suggest we implement is_numeric() and alike or allow a second parameter
that to 'is_*($vaue, $strict=true)' that allows to switch to non strict
mocde. We then could easily allow 'numeric' as another type hint. Or in

I see absolutely no use in "strict" mode. Moreover, I consider it
harmful as it teaches people not to use dynamic nature of PHP but
instead pepper their code with unnecessary checks and irrelevant errors.
As I said, I see no difference that could matter to PHP programmer
between '1' and 1, and I don't see why we should encourage making this
difference.
I know there could be very special cases when it could matter, but
importance and frequency of such cases do not warrant, in my opinion,
their support by the syntax and the standard library of the language.

other words I see this as a completely separate discussion. There are
two discussions:
a) do we want native type hints
b) do we want an easy ability to deal with compatible types in type hinting

Just for the record:
a) I think the whole idea of type hints, especially with primitive
types, goes to a wrong direction - PHP is not a strictly typed language,
and shouldn't be.
b) However, on practical grounds, since we already have type conversion
for internal functions, it won't be too much trouble for a user
functions to do the same. On the other hand, making strict types for PHP
functions is nothing but trouble, IMO.

This is why I think it is not as separate as you think.

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

2008/4/18, Lukas Kahwe Smith mls@pooteeweet.org:

Hello All,

I just want to bring in a different perception on the proposed feature. I
think people are very focused on what I call "library code". This is the
kind of code that should in theory be worked on less, than the glue code
that you write in every project to finish up the applications your customers
have requested.

IMHO type hinting and more importantly strict type hinting is very focused
with making the life of library developers easier. They can just easily
discard anything that doesnt match their expectations 100%. That this is not
how PHP has traditionally worked has been mentioned quite often in this
thread. But I want to direct peoples attention to the code that calls
strictly typed libraries.

Suddenly I need to ensure that all my variables have the proper types. So
what will people do? They will start forcing type juggeling manually before
they call the library in question. Since this is the glue code, its the kind
of code you have to write day in day out. So maybe an "(int)" here or there
is not so much more code to type, but you can already see that code you safe
on one end, you have to start adding on the other, the one which you write
more often. More importantly, in some cases simple type juggeling with
"(int)" will not be sufficient, you might have to do some minor checks etc.
In the past library authors did this as part of the code that the strict
type hinting camp is now hoping to remove. So again more code in my glue
code.

Furthermore people over estimate the usefulness of automated errors. They
tend to include very minimal context information. So when in the past people
had to write out the parameter checking code manually, they had the
opportunity to very easily add important context information to whatever
error they raised. This will no longer be the case with strict type hinting.
There it will be the responsibility for the caller to make sense of the
error and know whatever context is relevant for this error condition.

I guess the reply I can expect from this mail is that I do not have to use
it, that I do not have to use libraries that use strict type hinting or that
good developers will pick and choose when to use strict type hinting. While
this may be true, we do not live in a perfect world. So again I want to
remind people that as we develop the language, we need to pick and choose
what features come in that will ensure that PHP remains at least as
productive has it has been in the past for its users.

As such I want to again bring up that a loose type hinting with types like
"scalar" and "numeric" are much less risky, since they are a much wider
filter. Its quite easy to figure out why a function that is documented to
not operate on arrays to come back with an error when I pass it an array.
However it will be a bit confusing to get an error when I pass '1' to a
method that then comes back to complain I did not pass an integer.

regards,
Lukas

--

I think that this functionality can work for numeric types like this:

if we have one of the numeric types hinted for function arg then we need to
check if it is_numeric and if it is - we can convert it. If we have a string
witch can't be converted to regular numeric type without loosing information
(strings like "45s", "asdf32325" etc) - rase a recoverable error (or
exception - that way user can catch it and display it's own error text or do
some actions about it).
That way I think we won't lose the flexebility of PHP's dynamic type
conversions but we will make it a little bit more strict on what we are
passing to function (realy, if it is possible that string will be passed to
function where you have to have integer - don't you check it anyway for
correct type and value? Mostly on that check result is an error
triger_error/exit/die/etc.).

Suddenly I need to ensure that all my variables have the proper types. So
what will people do?
....
So maybe an "(int)" here or there
is not so much more code to type, but you can already see that code you safe
on one end, you have to start adding on the other, the one which you write
more often.

You are right, of course. I stated before that the hints automatically
casting the parameter is the best approach. With automatic casting,
which seems to be fairly obvious semantics for type hints, you will
not need to cast at call-time.

More importantly, in some cases simple type juggeling with
"(int)" will not be sufficient, you might have to do some minor checks etc.
In the past library authors did this as part of the code that the strict
type hinting camp is now hoping to remove. So again more code in my glue
code.

There isn't a strict typing camp. Felipe's first patch was just
checking, which didn't provide any guarantees to the library author.
The second was strict typing, which provides guarantees, as you say,
at great expense. I am hoping that the third will be casting, which
provides guarantees, at no call-time expense.

Paul

--
Paul Biggar
paul.biggar@gmail.com

Lukas Kahwe Smith wrote:

Suddenly I need to ensure that all my variables have the proper types.
So what will people do? They will start forcing type juggeling manually
before they call the library in question. Since this is the glue code,
its the kind of code you have to write day in day out. So maybe an
"(int)" here or there is not so much more code to type, but you can
already see that code you safe on one end, you have to start adding on
the other, the one which you write more often. More importantly, in some
cases simple type juggeling with "(int)" will not be sufficient, you
might have to do some minor checks etc. In the past library authors did
this as part of the code that the strict type hinting camp is now hoping
to remove. So again more code in my glue code.

You're absolutely right about that glue code. However, I think this serves as
a benefit for the developers using the library/framework/component/whatever.
It reduces the chances of passing wrong types around, he's forced to grapple
with the parameter in a proper way and would, ahead of executing code with
possible wrong values, have a change to correct it.

Yes, the code can likely look like

$foo->bar( (int)$baz, (string)$sober, (bool)$result['column_checkbox'] );

but this means he is really forced to think what he is really passing. It will
not raise the overall code quality in a major way, but it helps developers on
both sides (devs of libraries, devs of using the libraries) to ensure proper
passing of varaibles.

It is optional. And it will likely be only used by
library/framework/component/whatever. But for them, I think, it's a win.

sincerely,

• Markus