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 
)
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).
