Type safety in PHP

[bradgrafelman]

I, too, tried to keep backwards compatibility in mind for every answer I gave on the survey.

One of my ideas was to by default make type violations an E_NOTICE/E_WARNING level error but to also add an option to error_reporting that would elevate these to catchable fatal errors.

EDIT: I should add... I came up with this idea without thinking of the approach Derokorian described (and/or what was described on the page traq linked to in post #12). I'm still on the fence as to which way I like better.

[traq]

What I would expect is that since $a != (int) $a that this usage would not produce 0 but instead produce a Fatal error

Right:

function intOnly( int $int ){}
intOnly( "a" );
/*
(int)"a" = 0
"a" != 0
throw error
*/
intOnly( "1" );
/*
(int)"1" = 1
1 == 1
okay
*/
# intOnly( "1thing" ); # strike that. better example:
intOnly( true );
/*
(int)true = 1
...?
yeah... that's where it gets muddy.
*/ 

One of my ideas was to by default make type violations an E_NOTICE/E_WARNING level error but to also add an option to error_reporting that would elevate these to catchable fatal errors.

Hadn't thought of that. Good possibility.

[NogDog]

As far as I'm concerned, if you specify...

function foo(boolean $bar) { ... } 

...and call it as...

foo(1); 

...it should throw an exception, just as it would if you type-hinted with "Array" or any class name. Automatically converting it to the desired type would not be "type safety", to my mind.

However, note any such implementation would now mean you could not call any of your classes "boolean" or any other implemented type names (which may already be reserved words?), or if you did, you could not use that class's name as a type-hint any more -- not that I'd generally want to call any of my classes that, but I suppose you could define classes to represent different data types as a way to implement type safety, by allowing you to type-hint with those class names?

Oh well, guess I'm just glad I've never really had an issue with PHP's loose typing (or whatever it's technically called?).

[traq]

As far as I'm concerned, if you specify...

function foo(boolean $bar) { ... } 

...and call it as...

foo(1); 

...it should throw an exception, just as it would if you type-hinted with "Array" or any class name. Automatically converting it to the desired type would not be "type safety", to my mind.

Agreed - just a little muddy, since (for example) 1 and 0 are so synonymous with TRUE and FALSE.
But where would you draw the line? Should "5" (a string) fail where an integer is required?

[NogDog]

Agreed - just a little muddy, since (for example) 1 and 0 are so synonymous with TRUE and FALSE.
But where would you draw the line? Should "5" (a string) fail where an integer is required?

In my mind, yes, since type-hinting means you only want to accept parameters of the specified type. If, instead, you want the normal loose typing, then simply do not type-hint for it (or embed your own type-checking/-swapping mechanism at the beginning of the function definition if you want something in between strict type-checking and no type-checking). But like I said, I'm not going to loose any sleep over it for now.

Hmm...now I'm imagining a class full of methods for various sorts of type-checking...darn you all, I have other things that need doing!

function enforceInteger(&$value)
{
    if(is_int($value)) {
        return true;
    }
    elseif((int)$value == $value) {
        $value = (int) $value;
        return true;
    }
    throw new TypeException("Not an integer");
} 

[bradgrafelman]

But where would you draw the line? Should "5" (a string) fail where an integer is required?

IMHO, yes, because:

gettype("5") != gettype(5) 

.

Otherwise, why not consider the character 'a' to be an integer? Any C program would be happy to evaluate:

('a' == 97)

as TRUE.

[rstoll]

What I would expect is that since $a != (int) $a that this usage would not produce 0 but instead produce a Fatal error.

Well, if

$a = "a"; 

then

$a == (int) $a 

evaluates to true because the == does make a weak comparision and thus $a would be castet to a int before it is compared against (int) $a and consequentely $a and (int) $a are the same.

but $a !== (int) $a. But if you compare it with === then it would be the same as having a strict type-safety as described by NogDog (what in my opinion makes absolutely sense).

Maybe it would be nice if a developer can decide on his own if he wants an auto casting or not. Maybe with a construct like this:

function foo (cast int $a){ //cast $a to int if $a isn't a int
//...
}
function bar(int $a){ // does not cast $a to int and therefore would throw a fatal error if a string is given
//...
} 

if someone would call foo with an object then also a fatal error would be thrown, since an object cannot be castet to int

[traq]

Well, if

$a = "a"; 

then

$a == (int) $a 

evaluates to true because the == does make a weak comparision and thus $a would be castet to a int before it is compared against (int) $a and consequentely $a and (int) $a are the same.

yeah... it'd have to be implemented some other way.

Maybe it would be nice if a developer can decide on his own if he wants an auto casting or not.

I'd thought about that. I was considering using

function foo( (int)$a ){ /* cast $a if necessary */ }
function bar( int $a ){ /* no casting; strict equality only */ } 

seems more intuitive to me.

*****

To answer bradgrafelman and NogDog,

I agree that casting "if equivalent" wouldn't actually work very well, and that, if you ask for a particular type you should expect the comparison to be strict. The only examples where I'm hesitant (that I can think of) is 1/0 vs. TRUE/FALSE and numeric strings vs. integers.

[NogDog]

...

function foo (cast int $a){ //cast $a to int if $a isn't a int
//...
} 

I do kind of like that, in that it makes it obvious what's happening just from the function prototype, regardless of what any comments or lack of comments may say.

[Derokorian]

Well, if

$a = "a"; 

then

$a == (int) $a 

evaluates to true because the == does make a weak comparision and thus $a would be castet to a int before it is compared against (int) $a and consequentely $a and (int) $a are the same.

but $a !== (int) $a. But if you compare it with === then it would be the same as having a strict type-safety as described by NogDog (what in my opinion makes absolutely sense).

ah but not if you did:

$a == (string) ((int) $a) 

where string is the type passed, if castable. Because "a" != "1" so it would fail.

Maybe it would be nice if a developer can decide on his own if he wants an auto casting or not. Maybe with a construct like this:

function foo (cast int $a){ //cast $a to int if $a isn't a int
//...
}
function bar(int $a){ // does not cast $a to int and therefore would throw a fatal error if a string is given
//...
} 

I like this way a lot.

[Weedpacket]

Maybe it would be nice if a developer can decide on his own if he wants an auto casting or not. Maybe with a construct like this:

function foo (cast int $a){ //cast $a to int if $a isn't a int
//...
} 

And if $a is passed by reference (function foo (cast int &$a){), does the source variable find its value also being cast?

$value = '42';
foo($value);
echo gettype($value); // "integer" or "string"? 

[traq]

And if $a is passed by reference (function foo (cast int &$a){), does the source variable find its value also being cast?

My impulse answer would be "yes," since you presumably know that you're passing by reference (and if you didn't, you'd have problems anyway).
I wouldn't expect the value to be modified (in any way) if it failed the test, however.

[traq]

An illustration. Still too many problems to actually be useful.

https://gist.github.com/4600808