Type safety in PHP

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 :slight_smile:

Thanks for your help
Robert Stoll

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.

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.

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.

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.

Heya,

Quite a long time ago (almost a year), I asked you guys to fill in a survey about type safety in PHP which I conducted in context of my bachelor thesis.
Unfortunately, I did not really have time to publish all results on a website so far but I am happy to announce that you can find the results here now:
http://tsphp.tutteli.ch/wiki/display/TSPHP/Results+online+survey+Type+Safety+in+PHP

My bachelor thesis serves as a basis of the open source project TSPHP. You can find further information about it on the wiki as well:
http://tsphp.tutteli.ch/wiki/display/TSPHP/Overview

Please don’t hesitate if you have further questions about the survey or the project.

Cheers,
Robert

Sounds interesting. PHP does not have return type hinting, which makes it less type safe compared to strongly typed languages. On the other hand, PHP’s type juggling capability is powerful and flexible, but it comes with a cost to type safety as well. Also I believe implementing the language feature of Generics will further enhance type safety, as it can be used in collection classes/array objects. Currently a PHP array is definitely not type-safe, some restrictions can be enforced by extending PHP’s ArrayObject/SplFixedArray class and the overriding its offsetGet and offsetSet so that they check object types. Nonetheless, this means that you have to create one subclass of ArrayObject/SplFixedArray for every type you want to enforce type-safety in a collection. It will require quite a bit of changes to make PHP a truly type-safe programming language.

One comment Id like to make regarding return type hinting in your survey. I was wondering whether the keyword ‘function’ can be omitted if return type hinting is used. The following syntax below makes better sense to me, as specifying a return type after the keyword ‘function’ makes the code looks ugly:


public string getName(){
    //...
}
public void setName(string $name){
    //...
}

If return type hinting is optional, the keyword ‘function’ cannot be omitted as the compiler wont be able to tell that it’s a method compared to a property. Well in languages like javascript this is not a problem, but for PHP I’m sure theres a reason why distinguishing properties from methods is necessary. To summarize, the keyword function in method signature is used as identifier for methods that do not follow return type hinting, when return type hinting is used the keyword function is replaced by the return type. Of course this assumes that only method return type hinting is implemented, but not with property type declaration(so nothing like public string $name).

As a general answer, PHP isn’t type-safe at all, it just gives the user the possibility to define some constraints with type hints but they are not binding. For instance, I can still write (the valid code)


function foo(Foo $foo){
    $foo = 1;
}

Personally I think it is not bad that PHP is weak typed and not type-safe. I think PHP has become so popular exactly due to this “sloppiness”. It’s a language which is very easy to learn and still powerful and besides, everyone can write in a type-safe manner if one likes. The project TSPHP does not try to change that and therefore is introduced on a higher level than PHP (thus without changing PHP itself). It could be seen as the type-safe counterpart of PHP (or you could think of a very big DSL based on PHP where the domain is type safety ^^).

I totally agree, but I don’t think it makes really sense for PHP itself. Consider the following:


function foo(array<int> $arr){
    $arr[] = "muahaha"; //will still be possible
}

As you can see, as long as PHP is not completely type-safe this feature is more or less useless and it would also cause an undesired performance penalty because array<int> would actually mean that PHP has to verify the content of $arr before it can be used and thus would be something similar like the following userland code:


function foo(array<int> $arr){
    for($arr as $value){
	    if(!is_int($arr[$i]))  trigger_error("xy",\\E_USER_ERROR);
	}
	//and now do something
}

That’s why I don’t think it would be clever to introduce generics in PHP. However, generics make perfect sense in TSPHP (aim is to introduce it in v. 0.8.0 of TSPHP). Just to avoid misunderstandings, TSPHP demands complete type safety (there won’t be something like optional type safety). Generics would simplify the usage of arrays in TSPHP because right now, arrays can just hold objects of type object and hence one has to cast to the appropriate type when reading from an array. With generics this would become needless.

Indeed, a big effort is needed and the changes are just one reason why I doubt PHP will become once a type-safe language because the changes would imply a huge BC break at some point.
In my personal opinion, I think a compile time approach (as TSPHP follows) is the right one because it enables complete type safety for those who want it, does not result in performance penalties (there are actually performance improvement opportunities) and does not hamper PHP to evolve further as language.
One big drawback: TSPHP has to be maintained in parallel to PHP and the implementation of TSPHP itself is already a huge effort (contributors are welcome :wink: )

An additional benefit of the compile time approach is, that one has the possibility to go back to PHP (without type safety) because all TSPHP code is translated to PHP at some point. There is somewhat a forward compatibility between PHP and TSPHP (not a backward compatibility though - PHP code does not compile as TSPHP code, but I am already thinking about a solution for this issue).

I think there is also another factor which shouldn’t be underestimated. Type safety means also an additional learning curve. I tried to simplify the change to TSPHP and the need for additional type definitions by introducing new constructs. As an example the cast assign operator and the [URL=“http://tsphp.tutteli.ch/wiki/display/TSPHP/cast+modifier”]cast modifier which should ease the usage with types.
Still, there are other improvements which could be implemented to simplify the usage with types such as type inference.

That’s actually a good point. I was thinking about it at the beginning of the project and decided at the stage that one has to write function as well. My decision was based on the reason that the transition from PHP code


function foo(){}

to TSPHP code


function void foo(){}

would be easier. Nevertheless, I just created a change request (TSPHP-645) and I will at least reconsider to make function optional (then code conventions have to define whether the developer should write function or not).