Type safety in PHP

[rstoll]

Hi,
I am currently working on my final project of my undergraduate study and the project is about type safety in PHP. One aspect of the project examines the opinion of the PHP community on this topic.

I now need your help. I would be very glad, if you could take 5 – 20 minutes to fill in my online survey: http://www.q-set.co.uk/q-set.php?sCode=PGSKQCJUWZVK

I will publish the deliverables of my project under an open source license. Thus you contribute automatically to an open source project if you fill in the form

Thanks for your help
Robert Stoll

[Ashley Sheridan]

Just filled it in, I realise how difficult it can be sometimes to get a large enough pool of data for university coursework.

[dalecosp]

Hi, Robert, and welcome to PHPBuilder!

I found the concept interesting, if a tad on the political side

2. Should the following improvement for type safety be made?

public function setName(string name) { 

I'd say it should be optional, but that option wasn't available here

A context for templates is introduces.

I'm fairly certain you meant to use the past tense here?

securer web applications

Sounds a bit odd. How about "Improved security and robustness in web applications."

Hopefully not keeping others from participating, I also found the second set of questions rather awkward, as my opinion hadn't changed at that point.

The IDE section was interesting.

Note that for US participants, "College Degree and Bachelors' Degree" will, generally, be synonymous.

Good luck with your project!

[rstoll]

@Ashley Sheridan
Thank you very much

I found the concept interesting, if a tad on the political side

I know, can be quite controversial. But that's ok

2. Should the following improvement for type safety be made?
PHP Code:
public function setName(string name) {

I'd say it should be optional, but that option wasn't available here

Hm... I have not given this option because types for parameters are already optional, but maybe it would have been better to give that option as well.

securer web applications

Sounds a bit odd. How about "Improved security and robustness in web applications."

Thanks for your suggestion

Hopefully not keeping others from participating, I also found the second set of questions rather awkward, as my opinion hadn't changed at that point.

Since not everyone get the same questions (depending on the answers given) I would like to know, which kind of questions you are talking about?

Note that for US participants, "College Degree and Bachelors' Degree" will, generally, be synonymous.

Thank you, I didn't know that

Good luck with your project!

thanks

[dalecosp]

Since not everyone get the same questions (depending on the answers given) I would like to know, which kind of questions you are talking about?

Hopefully I can explain

After I was asked ("does knowing about this change your thoughts"), [around #9 or #10, I think], I was then asked the exact same questions; six or seven of them, I think. As I hadn't changed my mind, I didn't see the point in being asked the same questions again. Perhaps I didn't understand something I clicked, and it went back and began again?

[rstoll]

oh no... that's exactly not what I wanted Those questions should have been skipped when you choose no your opinion hasn't changed.
Thank you for your hint.

[rstoll]

Hopefully I can explain

After I was asked ("does knowing about this change your thoughts"), [around #9 or #10, I think], I was then asked the exact same questions; six or seven of them, I think. As I hadn't changed my mind, I didn't see the point in being asked the same questions again. Perhaps I didn't understand something I clicked, and it went back and began again?

hm... I just tested it, probably you have used the back button, since I do not get the same questions again, if I choose no for the question: "Would you have answered the previous questions differently if you had had the above information?"

[dalecosp]

Well ... the problem with that theory is that the question numbers continued to increment as expected.

[rstoll]

Ah... I see. That's true, unfortunatley that's how the survey web application is implemented. But I can activate a page number in addition next to the question numbers (already done now). This way it is more obvious that some questions have been skipped. Thank you for your hint. I think that's helpfull for the participants.

[traq]

I tried to take your survey several times, but it kept restarting at random points. I got about halfway through.


I think many of the examples you give are over-simplified: you often ask "if _x_ should be done to improve type safety" - but you don't necessarily explain how _x_ will be implemented.

For example,

public function whatever( string $str ){ /*...*/ } 

What does string _do_?

...Does it throw an exception if $str is not a string (which could come to pass under any number of coincidences in a loosely typed language like PHP)?

...Does it cast $str to a string?

...Does it cast $str to a string, but only if $str == (string)$str?
(...BTW, this is the answer I would have chosen)

...What about

public function whatever( string $str="default" ){ /*...*/ } 

Is $str given the value "default" if it is not a string?
Or only if it is not provided?

On several questions, I found it difficult to choose an accurate/meaningful answer because of ambiguities like these.

*****

Regarding templates, I think the best (simplest, most obvious) solution would be to create a template object and pass (or use?) the desired variables directly to it.

*****

Dynamic typing is a benefit, not a shortcoming. Full type safety would completely break many PHP applications. I'm not advocating that backwards-compatibility should be the deciding factor, and while a measure of type safety (or perhaps type hinting and stricter control over type coercion is what I really mean) would be beneficial, it could also lead to unnecessarily complex code.

As an example, $_GET and $_POST are always initially strings - do you intend to initially cast them to a "best fit" type? According to what rules? Or would one be forced to write constructs like

function whatever( int $int ){ /*...*/ }
$result = whatever( ((integer)$_GET['userInt']) ); 

?

[Derokorian]

...Does it cast $str to a string, but only if $str == (string)$str?
(...BTW, this is the answer I would have chosen)

As I would have also chosen.

[traq]

As I would have also chosen.

Have you read this (I don't remember where I was pointed to this; it may have even been here (on phpbuilder), so my apologies if we've already had this discussion)?

[rstoll]

I think many of the examples you give are over-simplified: you often ask "if _x_ should be done to improve type safety" - but you don't necessarily explain how _x_ will be implemented.

Fair enough. I see what you mean and I see, that it is difficult to choose an option if one think about it as you have done. I have explicitly left out any implementation, since the survey would be even longer with it and honestly, I think now that it is already too long, I should have shorten the survey a little bit. First of all I have thought about implementing a very strict model which would have needed an explicit casting. For instance a method call would have been

int $a = 1;foo( (string) $a); 

However, I have made some speed tests and have realised, that explicit casting is slower in PHP than the PHP intern casting. For instance:

$a = 1; 
$b = (int) "1"; 
$c = $a + $b; 

is slower than

$a = 1; 
$b = "1";
 $c = $a + $b; 

Therefore I am not yet sure how I am going to implement it.

...Does it cast $str to a string, but only if $str == (string)$str?
(...BTW, this is the answer I would have chosen)

I am not sure if I really get what you mean. Take your example with an integer. For instance:

function foo(int $i){
  echo $i;
}
$a = "a";
foo($a); //output = 0 since $a == (int) $a; 

Is this really what you want? Or would your behaviour only be applied to strings?

Regarding templates, I think the best (simplest, most obvious) solution would be to create a template object and pass (or use?) the desired variables directly to it.

I agree, that would be the simplest way, but I believe developers are still heavely relying on templates (including other files). I mean, it is already possible to use objects instead of including files (needless to say that classes will also be included at a certain point) but one like including files without context more than defining classes and using them. I undestand them, since including files is quite convenient.

Dynamic typing is a benefit, not a shortcoming. Full type safety would completely break many PHP applications. I'm not advocating that backwards-compatibility should be the deciding factor, and while a measure of type safety (or perhaps type hinting and stricter control over type coercion is what I really mean) would be beneficial, it could also lead to unnecessarily complex code.

I absolutely agree. Type-safe code leeds often to more complex code than unsafe code. I think one good point in my approach is, that I introduce TSPHP at a higher level. PHP is still available as it is now and for certain web applications it is more appropriate to use PHP rather than TSPHP. And since TSPHP is translated into PHP one can develop his component in TSPHP and another one show use PHP can use the component (unfortunatley not the other way round - but if TSPHP is usefull as I expect it to be then I will probably also develop a type inference system which transforms PHP into TSPHP as far as possible). However, especially bigger projects which underlies many changes (over the years) are quite painfull to maintain, because refactorings for PHP is poorly supported by IDEs and quite error prone. If you have done ones a refactoring in type-safe languages you exactly now what I mean. And in my opinion refactoring is very essential to keep your code quality high over the years and changes.

As an example, $_GET and $_POST are always initially strings - do you intend to initially cast them to a "best fit" type? According to what rules? Or would one be forced to write constructs like

function whatever( int $int ){ /*...*/ }
$result = whatever( ((integer)$_GET['userInt']) ); 

?

Well, as said above, first of all I intended to implement a very strict model, but now I guess I will accept some operator overloadings. For instance

string $b="1";
 int $a = 1 + $b; 

will be valid, since + automatically casts strings to integers. However, I am not yet sure how I will implement it for parameters. I was thinking about a strict model (thus (integer)$_GET['userInt']; whould be necessary) but with the option of an automatic casting. Anyway, I haven't made final decision yet.

[rstoll]

$a = 1; 
$b = (int) "1"; 
$c = $a + $b; 

is slower than

$a = 1; 
$b = "1";
 $c = $a + $b; 

I have to correct myself. Explicit casting is as fast as implicit casting.
Nevertheless, I will support operator overloading as mentioned and I will be strict on parameters but with the possibility to activate automatic casting.

Have you read this

The syntax for the automatic casting could therefore be

function foo((int) $i){} 

but maybe also something more obvious as

function foo(cast int $i) 

[Derokorian]

I am not sure if I really get what you mean. Take your example with an integer. For instance:

function foo(int $i){
  echo $i;
}
$a = "a";
foo($a); //output = 0 since $a == (int) $a; 

Is this really what you want? Or would your behaviour only be applied to strings?

What I would expect is that since $a != (int) $a that this usage would not produce 0 but instead produce a Fatal error, much like that which would result from the following:

function TrimPost(BlogPost $post) {
   $post['body'] = substr($post['body'], 0, 200);
   return $post;
}
$a = new User();
TrimPost($a);
// Catchable fatal error: Argument 1 passed to TrimPost() must be an instance of BlogPost, instance of User given, called in /path/to/file.php on line ## and defined in /path/to/file.php on line ##