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

[pbyrne84]

You may want to read this https://wiki.php.net/rfc/returntypehint2 as the keyword function becomes an alias for return type mixed for backwards compatibility and maybe change your form to represent this as I believe this is the latest rfc even if it is a bit old.

[StarLion]

I find the survey to be... misleading/incomplete.

You start to say "This will not affect PHP in any way"... and then in the next question propose changing the syntax of the function command.
So... i cant complete the survey correctly.

[Serenarules]

I took your survey, out of curiosity. But I think some discussion could be held here on certain points as well. I realise most of this has been hashed and re-hashed many times over, here, on the PHP discussion groups, and elsewhere on the internet. Though, many of patrons do not visit such places.

I think the differentiation should be made between type hinting and type safety. The are fundamentally different and likewise, serve different purposes. Type hinting is an as-of-right-now check, while type safety is an at-any-time check. Variables, or return values, marked with a type hint are checked only at the time of entry or return. However, such variables types would still be mutable once the values have been obtained. With type safety, they cannot. Implementing full type hinting would only serve to better error reporting in PHP. Of course, I am not denouncing the impact of this. Rather, I am merely putting it into perspective. As I am primarily a C/C++/C# developer, I would prefer that both aspects be fully utilized, with an ini option to disable it globally, and a method to turn it off for the current script. That said, do I think it is required? No. Part of the charm of PHP is the overall mutability it has. But if done, it needs to be done correctly and completely.

[cpradio]

I think the differentiation should be made between type hinting and type safety. The are fundamentally different and likewise, serve different purposes. Type hinting is an as-of-right-now check, while type safety is an at-any-time check. Variables, or return values, marked with a type hint are checked only at the time of entry or return. However, such variables types would still be mutable once the values have been obtained. With type safety, they cannot. Implementing full type hinting would only serve to better error reporting in PHP. Of course, I am not denouncing the impact of this. Rather, I am merely putting it into perspective. As I am primarily a C/C++/C# developer, I would prefer that both aspects be fully utilized, with an ini option to disable it globally, and a method to turn it off for the current script. That said, do I think it is required? No. Part of the charm of PHP is the overall mutability it has. But if done, it needs to be done correctly and completely.

I agree with that. However, I also think that full type safety would be hard to implement in PHP since it isn't really a compiled language. Granted I guess once you start to serve up the page the JIT could find the errors and report them, but if you ask me, that is too late (from a developer perspective). That is one reason I really enjoy C/C#, I love the instant notification I can get by simply compiling my code.

Also, granted, several IDEs are very capable of detecting these errors on your behalf before your code is asked to be rendered/compiled too, so you could argue it could still be implemented on that level too. But I digress, if your IDE did that, do you really need full type safety? Wouldn't type hinting with IDE support for detecting errors be enough? The only thing I dislike about that idea, is you are separating responsibility, PHP is responsible for continuing type hinting, and IDEs are responsible for ensuring your code sends appropriate values to your type hinted methods, classes, etc. -- Seems very dirty.

[Serenarules]

I agree with that. However, I also think that full type safety would be hard to implement in PHP since it isn't really a compiled language. Granted I guess once you start to serve up the page the JIT could find the errors and report them, but if you ask me, that is too late (from a developer perspective). That is one reason I really enjoy C/C#, I love the instant notification I can get by simply compiling my code.

Also, granted, several IDEs are very capable of detecting these errors on your behalf before your code is asked to be rendered/compiled too, so you could argue it could still be implemented on that level too. But I digress, if your IDE did that, do you really need full type safety? Wouldn't type hinting with IDE support for detecting errors be enough? The only thing I dislike about that idea, is you are separating responsibility, PHP is responsible for continuing type hinting, and IDEs are responsible for ensuring your code sends appropriate values to your type hinted methods, classes, etc. -- Seems very dirty.

Exactly. Which is why I, overall, opt for the 'not required' option. And you're right. The way PHP handles certain scalars is not ameniable at the time for implenting type hints: string, int, etc).

Anyway, you bring home a point most people seem to miss. Compiled vs Interpreted. In addition, the original intent of the given language. PHP was designed to be fast, light-weight and mutable. While it has seen more use lately in larger projects (business driven distributed applications), that isn't what it was designed for originally. The language is progressing, as more and more web sites make use of advanced concepts, but it's going to be a long road.