Child pages
  • Interview 'What is TSPHP and what does it solve?'
Skip to end of metadata
Go to start of metadata

First of all, the following interview is fake. But it shall answer you several questions about TSPHP which you might have. If one of your questions is not answered after reading this interview then please contact and ask the question directly (might show up here afterwards).

What is TSPHP and what does it solve?

TSPHP is an open source project started in October 2012 in connection with the Bachelor Thesis - Type-Safe PHP: A compile time approach written by Robert Stoll. 
"Unspectacular Interviews" had the chance to meet Robert and ask him a few questions about TSPHP. Especially what the project tries to solve and by what it differs from PHP but also by what it differs from Facebook's project HHVM, Hack respectively, which has similar goals.

We started with rudimentary questions and got quit a bit into detail later on. If you are already familiar with TSPHP then you might want to skip the first few interview questions.

Enjoy reading!

"Unspectacular Interviews" team

What does TSPHP stand for and how does it relate to PHP?

R. Stoll: TSPHP stands for Type-Safe PHP and it relates to PHP in many ways, starting with the syntax which is more or less the same as in PHP and ending with the generated output which is PHP (you will find more detail about this in the question What does 'TSPHP is a layer on top of PHP' mean exactly?)

What was the motivation behind TSPHP?

R. Stoll: The motivation was mainly built on personal experience made in PHP projects. People were writing really ugly code and they have not even been aware of that fact sometimes because they turned off the error reporting by default.
I had to fix quite a lot of bugs which would not have been possible to introduce in the first place, if the project were written in TSPHP. Please have a look at Motivation behind TSPHP for more information.

What is the vision of TSPHP? 

R. Stoll: The vision is to provide a type-safe alternative of PHP for all those users which actually want type safety in PHP. The project does not intend to incorporate type safety into the core of PHP nor writing an extension for PHP. It is a project on its own parallel to PHP. More information can be found in Vision of TSPHP.

Interviewer: So if I get you right, TSPHP tries to solve the problem that type safety is missing in PHP?

R. Stoll:  I would not phrase it this way but basically yes. I am sure not everyone reading this would agree that the missing type safety as such is a problem and I would not either. In my personal opinion, PHP should not be type-safe. It is a dynamic and weak typed programming language and I think that is perfectly fine because it has its merits as well. Changing this would change the language’s paradigm and that would be wrong.

Interviewer: Ehm... so why did you came up with TSPHP again? 

R. Stoll: Do not get me wrong, PHP as such should not be type-safe does not mean that a type-safe variant of PHP is useless. Not at all, the days where PHP was only used as a scripting language are long gone and really complex web applications are built with PHP these days. And that is where TSPHP fits in nicely. TSPHP can ensure type safety during compile time and thus can prevent that the user introduces certain bugs in the first place. That is one point. Another point is that refactoring support can be more sophisticated for a statically typed language compared to a dynamically typed one and I think that is quite crucial to keep the code quality up high when a project gets bigger and bigger.

Under what license is TSPHP published? 

R. Stoll: Under a permissive open source license, namely Apache License 2.0 - see License.

What means type safety during compile time?

R. Stoll: Since TSPHP is translated back to PHP (see below What does 'TSPHP is a layer on top of PHP' mean exactly?) and PHP itself is not type-safe, TSPHP cannot guarantee type safety during runtime. This might sound like one loses type safety entirely but that is not true of course. Let me elaborate on this with the following example. First the TSPHP code: 

class Bar {
    function void hello() {
        echo 'hello world!';
function mixed foo(bool $a) {
    if ($a) {
        return new Bar();
    return false;
mixed $foo = foo(true);
if ($foo !== false) {
    Bar $bar = (Bar) $bar;

and the corresponding PHP code which is generated by the TSPHP compiler:

PHP code
    class Bar {
        public function hello() {
            echo 'hello world!';
    function foo($a) {
        if ($a) {
            return new Bar();
        return false;
    $foo = foo(true);
    if ($foo !== false) {
        $bar = ($foo !== null ? ($foo instanceof Bar ? $foo : \trigger_error('Cast failed, the evaluation type of $foo must be Bar', \E_USER_ERROR)) : null);

I have chosen on purpose an example with mixed as return type which basically means everything can be returned (as in PHP). But, as you can see, the TSPHP compiler (more precisely the translator component) has included a runtime check for the cast to Bar. This is the only additional runtime check which is necessary all other checks are done during compile time (by the typecheck component).That also means that scalar type hints (such as the type hint for the parameter $a of the function foo) are missing in the PHP code.

One reason why I define TSPHP as "type-safe during compile time" is that if the output code (the PHP code) is used in another context (e.g. in a purely PHP project) then TSPHP does not guarantee type safety. As an example, one can still pass a string instead of a bool to the function foo if one calls it in PHP. The compiler would cause a compile error if one tries to call a function with the wrong types in TSPHP though.

Interviewer: But would it not be possible to add further constraints to the output code to ensure type safety also during runtime?

R. Stoll: Theoretically the translator component could add constraints to ensure type safety for this particular case. For instance, the translator could add the following check at the beginning of the function foo:

PHP code
    \trigger_error('The evaluation type of parameter $a must be bool', \E_USER_ERROR);

But, that would mean a performance loss for all TSPHP users because this check is now performed at runtime every time the function foo is called and it is enough to perform the check once during compile time.
Yet, it would be very easy to extend the translator in order that it adds such checks or it would be possible to add a configuration flag instead which determines whether the translator adds the additional checks or not. However, this feature is not a requirement right now and therefore will not be implemented. But everyone can submit a feature request if one misses a feature in TSPHP through the issue tracking system.

Nevertheless, there are features which are not yet supported by TSPHP which will require further runtime checks.

Interviewer: Could you please give us an example of such a feature?

R. Stoll: One feature is serialisation and deserialisation. Basically, the TSPHP compiler just needs to know that PHP provides the function "serialize" and "deserialize" to support it, but it is another story to make such a feature type-safe without changing the core of PHP. I am not sure yet how I will ensure type safety for deserialisation and I am not sure either if I will include a check per default because it would slow down the deserialisation process in addition. 

Interviewer: But can TSPHP be considered to be type-safe without the additional check for deserialised objects?

R. Stoll: I would still claim that TSPHP is type-safe during compile time. Even type-safe during runtime if the runtime code is never modified. So if the output code and the serialised objects are not modified, then TSPHP would remain type-safe during runtime. One could also argue that a check is not necessary because the source of deserialised objects can be trusted. If it cannot be trusted then one has a security issue anyway and needs different checks such as digital signed objects etc.

Yet, there are other features next to serialisation and deserialisation which will need additional type checks. One of it is reflection. I am not sure yet how TSPHP is going to support reflection without breaking type safety. Might be that TSPHP will have some limitations compared to PHP.

Interviewer: I come back to limitations later on. But before that I would to look at the TSPHP syntax again (see code example above). I can see that the syntax of TSPHP looks very similar to PHP's syntax but not always. Thus...

How does the syntax of TSPHP differ from PHP's syntax?

R. Stoll: One might think TSPHP's syntax is an extension of PHP's syntax but that is not only the case. The additional type definitions can be seen as extensions but there are also restrictions due to the goals in the Vision of TSPHP. But let us look at the differences first.


R. Stoll: The differences mainly lie in the fact that TSPHP requires further type definitions.

Interviewer: And where exactly are those further type definitions required?

R. Stoll: Basically in every declaration/definition. That means you will need to specify (compulsory)

: Are there further differences concerning the syntax?

R. Stoll: Actually there are a few details which one has to be aware of when using TSPHP, the compiler would complain if you write it the wrong way respectively. I give one example (further information can be found in Valid in PHP but not in TSPHP).

For instance, pseudo optional parameters. I call them this way because the syntax looks like one specifies an optional parameter but it is not optional in any case. I am talking about the following scenario:

PHP code
function foo(MyClass $a=null, MyOtherClass $b){} 

$a is an pseudo-optional parameter in this case and TSPHP would complain about it. One can use the ? operator after the type to define that this parameter can also contain null. Like this

function void foo(MyClass? $a, MyOtherClass $b)

One can still use optional parameters if one likes but they have to be at the end of the parameter list. In my opinion this improves readability.

Another point is how the ternary operator is implemented in TSPHP. It is right associative, as in most programming languages, in contrast to PHP which has implemented it left associative (see Operator Precedence for further information).

Not yet supported

R. Stoll: TSPHP does not support all concepts of PHP yet (for instance closures) and not yet all operators. As an example, the short ternary operator is not yet supported but it will be supported soonish (see task  TSPHP-607 - Getting issue details... STATUS ). 
Please have a look at Scope to see what was not supported at the end of the Bachelor Thesis - Type-Safe PHP: A compile time approach. Missing features are added to TSPHP during each iteration. 

Not supported

R. Stoll: Some syntax is not supported in TSPHP and will most probably never be supported:

  1. Alternative syntax for control structures, e.g if(xy): z; endif;
  2. boolean, integer and double/real as alternative for bool, int and float. Only the latter group is supported

Interviewer: For what reason?

R. Stoll: Because TSPHP wants to reduce twin syntax (see Vision of TSPHP). I refer twin syntax as syntax which already exists and therefore can be written in a different way. Yet, the goal is not to reduce syntactic sugar such as += or ++ but syntax which does not add a benefit and rather hamper the readability and can confuse the user. The alternative syntax for control structures is definitely such a syntax in my opinion, because it does not add anything compared to the normal syntax and only means that the user has to learn an additional syntax without benefits.

The alternatives boolean, integer and double just confuse a user sine they have the same meaning in PHP as bool, int and float. Consider the following code

would cause a compiler error
int $a = 1; 
integer $b = $a; // is integer a different type than int? 
                 // can $a be assigned to $b? 
                 // -> would cause a compiler error, integer is an unknown type


Interviewer: Are there also new syntax features in TSPHP?

New syntax

 R. Stoll: The additional type definitions are kind of a new syntax but I already covered them before in differences. Nevertheless, TSPHP supports two new syntax features in addition which extend the PHP syntax (more will follow):

They both ease the handling with types, casting respectively. Since more or less all input in PHP is treated as string one has to apply casts at one point or the other. Please have a look at the two pages above for more information.

Interviewer: I had a look at the cast modifier and it seems to me that it randomly includes castings and thus might cause unexpected behaviour and one loses type safety somewhat. Why does TSPHP introduce such a modifier?

R. Stoll: That is not totally wrong. One has to be careful using the cast modifier because one can lose information if it is used careless. Following one example:

int $a = 1012;
cast bool $b = $a; //loss of data during the conversion - $b is now true
$a = $b; //$a is of type int but contains the bool true
echo $a + 1; //output 2

It was introduces mainly for those users which do not want to think about Type juggling for scalar types too much, pretty much as they are used to it in PHP. As I showed above the cast modifier can be a source of bugs and I guess code conventions of bigger frameworks might well forbid the usage of this modifier.

Nevertheless, the cast modifier does not include randomly casts as you claimed. It only includes a cast if and only if one exists and only for assignments. Thus the following code would cause a compiler error:

Would cause a compiler error
cast int $i = $_GET['quantity']; // perfectly fine 
if($i) { //bool expected, cast modifier does not include automatically (bool)
  $i = new Foo(); //cannot assign Foo to int, cast modifier does not include (int) because Foo cannot be casted to int

As you can see, one does not lose type safety. The cast modifier can be quite handy especially for functions which deal with input. Yet, as I said, one has to be careful using it.

: We were talking mostly of syntactic differences so far. 

How does the semantic of TSPHP differ from PHP's semantic?

R. Stoll: First of all, the type safety aspect plays a big role next to others. The following list is not complete but should give you a general idea of additional checks:

  1. A variable has to be declared (declaration in PHP is implicit)
  2. A variable cannot change its type as in PHP
  3. Forward usage of variables is forbidden, cause a compiler error respectively (causes only an E_NOTICE in PHP)
  4. Variables cannot be used outside of a conditional scope (see Variable Scope for more details)
  5. Local variables have to be initialised upon their first usage (causes only an E_NOTICE in PHP)
  6. A function or method either does not have a return type, void respectively, or exactly one return type
  7. A function which has specified a return type must return (return or throw statement) in all branches
  8. Constants which cannot be resolved cause a compiler error (causes only an E_NOTICE in PHP)
  9. Variables which cannot be resolved cause a compiler error (causes only an E_NOTICE in PHP)
  10. Basically everything which cannot be resolved causes a compile error. That means that one cannot write the following valid PHP code in TSPHP right now:

    Would cause a compiler error
    $a = new StdClass();
    $a->firstname = "Robert";
    $a->lastname = "Stoll";
  11. Expressions in an if or while condition have to evaluate to bool
  12. Operators are stricter than in PHP
    1. arithmetic operators work only for boolint and float (and their Nullable complement). The following statements would all cause a compiler error

      Would cause a compiler error
      "1" + "2";
      "a" - 1; 
      string $a = "a"; // that is fine, but not the next line
    2. the equality operator works only if either LHS and RHS evaluates to the same type or one is a sub type or one type can be casted to the other
    3. The identity operator works only if either LHS and RHS evaluates to the same type or one is a sub type. 

But there are other differences in behaviour next to further checks

  1. The array cast considers null in contrast to PHP

  2. The object cast is not supported by TSPHP (see object for further information)
  3. It might well be that a division with two int values will result in an int as well in a later version of TSPHP
  4. It might well be that the modulo operator only supports int and no longer float
  5. Fields without access modifier are implicitly public
  6. And I already mentioned Valid in PHP but not in TSPHP and one should also have a look at those points. They cover mostly differences in syntax but it is good to know them as well.

: Thanks, that is already enough information to talk about. I start at the top of the list and go down. 

Why do I need to declare variables?

R. Stoll: As I said above, declaration in PHP is implicit. You might not have noticed it but you have declared many variables in PHP because each time you write a variable name for the first time in code you declared it. So the question might be, why does TSPHP require it explicitly? Since a variable can only hold one type you have to specify which one and you do that once during the declaration of a variable. Have a look at Variables for more information.

Why do I need to initialise a variable before its first usage?

R. Stoll: Because TSPHP does not like laziness, sloppiness respectively (tongue). Your sloppiness can cause bugs which are hard to detect and a pain in the (you know what) for other developers which are not so sloppy/lazy as you are. Besides, PHP generates an E_NOTICE in the case you have forgotten to initialise a variable but if you are sloppy then the chance is high that you are lazy as well and have turned off error_reporting just to mute PHP from reminding you about your sloppiness (wink). Stick to PHP in conjunction with your configuration if you like to be a little bit lazy because the checks implemented in TSPHP would get on your nerves quite quickly.

As a side notice, I am not yet sure how TSPHP is going to support global variables since it is quite hard to detect whether a global variable is initialised or not (see Initialisation of global variables)

Why is only one return type allowed per function/method?

R. Stoll: This behaviour is quite common in type-safe programming languages and I decided to stick to this common behaviour in favour of readability.

Interviewer: Fair enough, but it is not really common in PHP. Even built-in function such as strpos return different types. How do you intend to cope with that?

R. Stoll: That is right and the main reason why TSPHP has kind of a strange type hierarchy (see Type juggling) compared to other type-safe languages is based on this fact. Right now, one can specify int as return type and still return a bool because bool is a sub type of int. Due to this type hierarchy strpos' return type will be defined as int in TSPHP. Unfortunately, I read about inconsistencies between scalar types which I was not aware of until recently and thus I might (have to) change the type hierarchy (see risk  TSPHP-675 - Getting issue details... STATUS ).

But besides, one can still return several types by using mixed as return type. mixed can hold all types and is similar to Java's Object or C#'s System.Object but TSPHP does not implement it as a class and mixed is really just a pseudo-type. 
I will most probably introduce the pseudo-type scalar which is the parent type of all scalar types (boolintfloat and string) which allows to narrow down the types which can be returned. 

Interviewer: Not only PHP has defined functions which return multiple types, many PHP users use the same approach. For instance, return MyClass or false in the case where something is wrong. How do such users have to write TSPHP code?

R. Stoll: The current approach is using mixed and is illustrated above in 
What means type safety during compile time?.
But I am aware of that especially returning false in the case where something went wrong is quite common in PHP. Hence, I was thinking about introducing a new construct in TSPHP to come up to this circumstance (see return-false-if-something-goes-wrong approach ). Although, personally, I consider it as a rather bad design and I would not suggest to return several types. 

Does TSPHP treat E_NOTICE as errors?

R. Stoll: That is right, TSPHP tries to ensure that no error regardless of what kind (E_NOTICE, E_WARGNING etc.) can occur during runtime. Yet, not all checks are already implemented at the moment (for instance TSPHP-422 - Getting issue details... STATUS ) and some are only runtime specific.

Interviewer: You were talking about that everything needs to be resolvable in order that the compiler is happy. But PHP has dynamic features which do not depend on resolvability. Such as dynamic fields (PHP calls fields properties) which you pointed out above as well. Therefore...

Does TSPHP support magic functions like __get and __set?

R. Stoll: TSPHP does not support magic functions at the moment (and other dynamic constructs - see question beforehand), but this will change. TSPHP will support magic functions but with the same restrictions as for normal methods though. As an example, the return type has to be specified for such functions as well or it might well be that the return type is fixed or parameters are only of type mixed and thus one has to cast first inside the magic functions etc. But that will be part of the implementation details when magic functions will actually be implemented in TSPHP.

Why does the if and while condition need an expression which evaluates to bool? 

Interviewer: Or if I phrase the question differently: Do I really need to write a cast to bool in each if condition? If I have a look at Type juggling and the current type hierarchy of TSPHP, I can see that everything casts explicitly to bool thus I do not really see the point why one has to write the cast.

R. Stoll: First of all, a cast is not necessary most of the time because if you compare something it evaluates already to bool. But if you place just a "naked" variable in the if (or while) condition and this variable is not of type bool, then you have to write a cast. The decision why you have to do this is actually based on my own experience. I saw many times that PHP users make the mistake as in the following example which will show you why it could be dangerous to leave the cast out: 

Would cause a compiler error
int $pos = \strpos("hello", "h");
if ($pos) { //would cause a compiler error: bool expected but int found

Due to the decision, one cannot accidentally write this code which is perfectly valid in PHP. The problem is, that if needle ("h" in this example) is found at position 0 (which is the case in the above example) then the if condition would evaluate to false which of course is wrong (at least if you want to check if needle was found in the haystack - therefore the big red warning box on the page of strpos). The TSPHP compiler would slap an error into the user's face and he/she will hopefully realise that one has to write the code as follows. 

int $pos = \strpos("hello", "h");
if($pos !== false){

As side notice, other type-safe languages enforces the cast to bool as well.

Why are arithmetic operations not allowed on strings?

R. Stoll: Because one can lose information inadvertently (e.g. "a" + 1) and thus it would be a source of bugs if one can use arithmetic operations on strings directly. So if you want to do arithmetic on strings you have to cast to int or float first. This does not prevent that one can loose information but one explicitly decides to do so and thus has hopefully thought it well through.

Interviewer: Does it not merely form an obstacle for the user? I mean, one can use arithmetic operators on strings in PHP.

R. Stoll: Yeah kind of but the intention of this "obstacle" is to force the user to think about what could happen and what he/she really wants/expects and secondly the readability is improved because it is explicit what is going on. In addition, I would say one does not need to perform arithmetic operations on strings most of the time since after an input validation one works already with the appropriate type (int or float).

Interviewer: Fair enough, but now the user has to decide whether he/she has to write a cast to float or to int whereas before, PHP made the decision for the user. I think this is rather a disadvantage than an advantage for the user.

R. Stoll: Well... I would not agree with that, because in the end, it does exactly what I want. One shall be aware of what one does. If one does not care that one can loose information then just write the cast. I would rather see it as a help for the user when he/she forgets that an information loss can occur and frankly, bugs like this occurs more often than you might think. So the compiler merely gently reminds the user about the fact that an arithmetic operation on a string can be dangerous.

It surely makes things more complicated for beginners but I do not see TSPHP as a language which is designed particularly for beginners (maybe in contrast to PHP). Furthermore, as I said already, it makes it explicit and thus favour readability and type safety as well. I mean, why would you want to cast to a float if you expect an int? Yet, as you can read between the lines it does not free the user from input validation that is still an essential part. Let us consider an example to make it clearer:

if (\is_int($_POST['quantity'])) {
    // =() is the cast assign operator and in this case is short for "int $quanty = (int) $_POST['quantity'];"
    int $quantity =() $_POST['quantity']; 
    // carry one with $quantity
    // error reporting to the user - int expected

In this example it is quite obvious that one will cast to int if one expects an int. From this point on, one will use $quantity and can perform all kind of arithmetic operations on it. There is no need to perform an arithmetic operation on $_POST['quantity'] directly.

Nevertheless, there is nothing wrong writing something as the following (in which one would cast to int as well):

if (\is_int($_POST['quantity'])) {
    int $price = (int)$_POST['quantity'] * $article->priceInCents;
    // carry on
    // error reporting to the user - int expected

: Could one not simply cast to float always? I mean, it would not really matter if it was an int instead, wouldn't it?

R. Stoll:  Kind of a lazy approach but I think it would work in most cases. Yet, I would encourage the user to get familiar with the differences between int (integer) and float (floating point number) and then it should not be that hard to make a decision.

InterviewerI saw in a previous example that string incrementation will not work in TSPHP. I understand that arithmetic operations on strings are not supported but...

Why does TSPHP not support string incrementing?

R. Stoll: Honestly, I was not even aware of that PHP actually supports string incrementation until recently. I consider it as a feature which is rather odd in PHP and as long as no one actually wants this feature I will not spend time to think about how TSPHP is going to support it.  

Inteviewer: Sounds like you only implement what you need.

R. Stoll: That is right to a certain degree. I am the only one contributing to this project at the moment and I am certainly not going to implement features which I consider to be useless for me right now. There is still a lot to do and string incrementation is not even on my list. But as I said, everyone is welcome to submit a feature request through the issue tracking system.

Why does the array cast consider null?

R. Stoll: Because null is a valid value for the type array (for more information have a look at array).

array $arr = (array) null; // $arr = null in contrast to PHP where it would be an empty array

Why does a division with two int values result in an int?

R. Stoll: This is not always the case in TSPHP right now, but this is rather a bug than a feature and will most probably change. For instance, 1/2 = 0.5 (a float) as in PHP at the moment. This will change because it is basically pretty standard in type-safe programming languages that int arithmetic yields an int. PHP behaves different because the user shall not be bother about to what type an expression evaluates. In contrast to TSPHP, which tries to make the user aware of types and tries to be more consistent. 

Interviewer:  Why do you reckon PHP is inconsistent in this point?

R. Stoll: PHP is inconsistent in a type-safe point of view. A division with two int values will either yield an int or a float depending whether the result is per se an int or not. That does not matter in PHP but I think it should in TSPHP. To be honest, it is somewhat hard to describe why...  maybe because int arithmetic on a processor yields an int and as such is faster than a float arithmetic (at least on most processors) and thus it just seems wrong to me to behave different. Well, performance is certainly not an argument in this case because TSPHP is translated back to PHP and PHP still uses the hybrid way of calculating things. So... yeah, still hard to describe.

Interviewer: If I do not interpret your statement wrong then I would say you are not yet sure how it is going to be in TSPHP, isn't it?

R. Stoll: You are right, I am not yet 100% sure. I could go with more or less the same approach as PHP and just define "a division always yields a float" and hence would be consistent as well but this solution would never favour performance. If I go for "a division of two int values yields an int" then I would argue that it is consistent with the modulo operator (see next point) and it is better in a long term view. I believe there will be an arithmetic division in PHP one day (even if I have to implement it) due to the better performance and furthermore it will be consistent to other type-safe programming languages which could be a benefit as well. But the decision is not fixed yet.

Why does TSPHP's modulo operator not support float?

R. Stoll: An impertinent answer would be because PHP's modulo operator does not really support float either. The through is, the modulo operator works only with int and if one uses a float in PHP then this float is just converted to int first (automatically, the user will not even noticing it). Consider the following code example:

echo (5 % 2.5);

What do you expect will be the result? 0 because the remainder of 5 divided by 2.5 is 0, or 1 because the remainder of 5 divided by 2 is 1 or maybe even 2 because the remainder of 5 divided by 3 (2.5 will be rounded up to 3) is 2.

As you can see it is not clear at all upon first sight. The result would be 1 because the modulo operator only works with int and the conversion from float 2.5 to int yields 2 (and 5 % 2 = 1). Thus it seems only logical to me that TSPHP will not support floats in order to improve readability and lower confusion.

What is meant by 'fields without access modifier are implicitly public'?

R. Stoll: That fields (PHP calls fields properties, I do not really like PHP's naming - properties always remind me of C# Properties) are implicitly public if one leaves the access modifier (public, protected or private) out. Pretty much as for methods in PHP and since TSPHP wants to reduce inconsistencies, fields behave the same way as methods. Following an example

class Dto{
  string $firstname; //same as public string $firstname
  string $lastname;  //same as public string $lastname


Interviewer: Okay, let us have a look at the last point in the list because I would like to go into one detail stated in Valid in PHP but not in TSPHP.

Why does TSPHP not support case insensitive identifier?

R. Stoll: The reason for this is based on two goals specified in the Vision of TSPHP which is "improve readability" and "lower inconsistencies". Case insensitive identifiers, more precise function/method/class/interface identifiers (names) as well as constant and variable identifiers, really hamper the readability of code in my opinion and are also against consistency. 

I guess most of the PHP developers are not even aware of that PHP has case insensitive names and they probably stick to the naming given in the PHP language reference manual. TSPHP just does not allow to have different cases for the same name. An example which would cause a compiler error:

Would cause a compiler error
function void foo(){}
Foo(); //Line 2|0 - Foo() was never defined

The function call has to be in the same case as its definition. I see now that the error message could be improved a bit in order that the user sees his/her mistake quicker (task created: TSPHP-693 - Getting issue details... STATUS )

Yet, TSPHP does not allow to define function names etc. which only differ in case. Thus the following would cause a compiler error as well:

Would cause a compiler error
function void foo(){}
function void Foo(){} // Foo() was already defined on line 1|14 

What else does TSPHP not support?

R. Stoll: Well, right now TSPHP is quite limited because it is still in its early stages. The compiler does not know anything about built-in functions from PHP or built-in classes and so on. However, this will change over time of course.

Nevertheless, there are a few things which TSPHP will most probably never support (please also have a look at Valid in PHP but not in TSPHP). I have already mentioned a few but like to sum up again:

That is all I can think of at the moment. I never use things which are not supported in TSPHP, thus it is quite hard to remember them.
Interviewer: Is this set in stone?

R. Stoll: Of course not, there is always place to reconsider some decisions. 

Interviewer: Let us talk again about inconsistencies, are you also thinking about renaming built-in functions in order to have one consistent API? 

R. Stoll: To be honest, it sounds tempting and I suppose quite a lot of PHP users and developers have already given some thoughts about making the names consistent but this goes far beyond the purpose of this project. TSPHP does not want to be too different in terms of naming and really just should be some kind of layer on top of PHP. So that's definitely a no-go.

What does 'TSPHP is a layer on top of PHP' mean exactly?

R. Stoll: The TSPHP project does not intend to change the PHP core and thus is really just a layer on top of PHP. That means, changes and additions to PHP are settled in this layer above PHP and when TSPHP is translated back to PHP after parsing, collecting definitions, resolving references and typechecking, one has normal PHP again which can be run with the common runtime environment as one has it today. That is already one of the few differences between TSPHP and Facebook's HHVM. But let me present you the compilation process in more detail (click on the image to enlarge it). 

The compilation process runs in parallel (denoted here with the two arrows) and synchronises after each (brighter blue) box. So first it parses and collects definitions of several TSPHP files (compilation units) in parallel. Once this is done it resolves references (again each compilation unit in parallel). Afterwards it type checks, optimisations could be done (is not yet implemented though) and finally the translation phase outputs two PHP files.


Interviewer: Let us speak about assets and drawbacks of TSPHP's approach. You were presenting the compilation process in the previous question. What are the assets of such an additional compilation?

R. Stoll: First of all, one has to be aware of that PHP itself has already implemented a compilation step which translates PHP code to Zend byte code (as far as I know). Yet, this is all done during runtime. So we have to distinguish between compilation during runtime which is part of PHP's interpreter and compilation during compile time, during development respectively, which is done with TSPHP's compiler in order to be able to discuss this topic and not merely compilation as such. That said, we should distinguish between an interpreted approach (as PHP takes it) and compiled approach (as TSPHP takes it) and compare those two approaches.

I recommend to have a look at wikipedia's article about this topic to get a second opinion: 

Interviewer: Ok, so could you please sum up assets and drawbacks of TSPHP compared to PHP instead.

R. Stoll: Sure

Interviewer: Let us start with.. 

Assets of TSPHP

R. Stoll: First of all just some general assets which the complied approach provides and which are not possible in PHP these days (however, they are not supported in TSPHP yet):

  1. Optimisations of code during compile time could speed up the runtime in addition
  2. Conditional compilation makes it possible to remove debug code in the release version entirely which in turn
    1. does not slow down your code undesired
    2. is somewhat safer in terms of security
  3. Enables that a real AOP implementation can be built
    • Be able to define PHP built-in functions as join points
    • Weave code in such a way that it does not result in a performance penalty during runtime
  4. Enables to have different versions of a third-party library in the same project
  5. TSPHP enables (within limits) forward compatibility to different PHP versions.
  6. TSPHP enables method and operator overloading without performance penalty

: All right, let us talk first about those assets before we go to TSPHP specific assets which are not yet covered here.

How can TSPHP optimise the PHP output code?

R. Stoll: TSPHP can optimise the PHP output code with pretty much all standard compiler front end optimisations which can be found in every book about compiler optimisation. Things like constant folding, loop enrolling and so on... I do not want to go into too much details here. The user merely has to know that TSPHP can optimise code before it even gets run with PHP. This means that a user has to worry even less about micro optimisations and can concentrate on the problem at hand and can write it in a clean way (without additional complexity due to performance optimisation).

Inteviewer: I am sure the reader would like to have a few examples. Could you please give us one?

R. Stoll: Sure. I give one
 concrete example which you can probably not find in a compiler book and should be quite evident for PHP users. If the compiler places the necessary includes in a PHP file and thus the autoload mechanism is less or not used at all, it will speed up your code (tests showed that an include is 100% faster than the include via the autoload mechanism. But have a look at the open source project Speedtest - a PHP framework to conduct speed tests to see more opportunities.

Interviewer: You said one can write cleaner code due to the optimisations. What were you referring to?

R. Stoll:  Following an example in PHP:

PHP code
public String getCode(String message) { 
    $now = date("d.m.Y");
    if ($forceAvailability || 
                   ($availableFrom == null || $availableFrom >= $now) 
                && ($availableUntil == null || $availableUntil <= $now) 
            )) { 
        return $code; 
    throw new NotAvailableException("code is not available anymore"); 

Could be written as follows instead (still PHP code) which is cleaner in my opinion

PHP code
public String getCode(String message) { 
    if (isAvailable()) {
        return code; 
    throw new NotAvailableException("code is not available anymore"); 
public bool isAvailable() {
    $now = date("d.m.Y"); 
    return $forceAvailability || 
                   ($availableFrom == null || $availableFrom >= $now) 
                && ($availableUntil == null || $availableUntil <= $now) 

One could argue that the additional function call is an unnecessary overhead in PHP. That is actually true but the overhead is quite marginal and there are certainly other bottlenecks in an application which are more severe than this additional function call. Nevertheless, TSPHP could optimise this code by inlining the function call and thus one really does not have to bother about such micro optimisations.

How can conditional compilation make your code safer in terms of security?

R. Stoll:  Well, I said it can make it somewhat safer. At the end it still depends on the user how he/she writes code. Security measurements could start with TSPHP removing all var_dump from code compiled in the release mode, but can go further by removing sections of code which should only be executed during debug mode (during development) and not in the release mode (during production).

Interviewer: But one could just use a const named DEBUG instead and depending whether it is set to true or false execute the corresponding section. Or do I miss something?

R. Stoll: Your described approach is quite similar to the conditional compilation but does result in a performance penalty. Compare the following two code snippets. The first is PHP code without conditional compilation and the second TSPHP with conditional compilation

PHP code
const DEBUG = true; 
function foo($a){
     does a few thing
     does a few thing
  var_dump($result); //inadvertently forgotten to remove
  return $result;




#if !DEBUG
function Bar foo(Bar $a){
#if !DEBUG
     does a few thing
     does a few thing
  var_dump($result); //inadvertently forgotten to remove
  return $result;

So far it looks very similar. However, the following would be the corresponding code in release mode:


function foo(Bar $a){ 
     does a few thing
  return $result;

Inteviewer: But one still needs to remember to compile the code in release mode, doesn't one?

R. Stoll: As I said, the user still has to think at the end of the day, TSPHP is not able to do that (wink)

What is meant by TSPHP can enable 'a real AOP implementation'?

R. Stoll: What I meant is that AOP implementations in PHP have most of the time a big runtime overhead and most of it are somehow coupled to a dependency injection container, use proxies or have another mechanism to "weave" code which needs additional PHP classes. The majority of those implementations have in common that they are not able to specify PHP built-in functions as join points.

Recently, I came across another project which does a pretty good job and even allows to define PHP built-in functions as join points. It literally parses PHP files before PHP itself parses it and thus is able to perform a better weaving. I am talking about Go! AOP. Yet, also this approach has a big runtime overhead as you might imagine and even though it uses caches to compensate most of it, it adds a runtime penalty compared to what is possible with TSPHP.
Due to the additional layer of TSPHP it would literally be possible to use everything as join point. That would probably go to far as well but just to stress the difference. And since the weaving could be done during compile time, one gets absolutely no runtime penalty.

Interviewer: Will AOP be a part of TSPHP core?

R. Stoll: No, not at the beginning at least but I will always keep AOP in mind when designing the language. In my opinion, AOP is still underestimated and people do not yet see that it could improve maintainability of code drastically.

How can TSPHP enable different versions of third-party libraries?

R. Stoll: Maybe I do not see all complications but I think it is quite straight forward to support it. TSPHP just needs to add the version number to the namespace in the output code. I was mainly thinking about the case where one uses a certain version of a library A (say 3.0) and another library B uses another version of library A (say 2.5). In this case the TSPHP user does not even realise that he/she is using version 3.0 where library B uses version 2.5.
Might be that this is only a concern of bigger projects but I think that is quite an asset compared to PHP. Have a look at  TSPHP-635 - Getting issue details... STATUS  for more information.

How is TSPHP able to enable forward compatibility to different PHP versions?

R. Stoll: Since TSPHP is an additional layer on top of PHP (see What does 'TSPHP is a layer on top of PHP' mean exactly?) it allows writing one TSPHP code which is then translated to different PHP versions thus provide forward compatibility. However, TSPHP does only have a translator component to PHP 5.4 at the moment and one would need to write other translator components to support other PHP versions. But theoretically it is possible to support all minor versions with one TSPHP code

Interviewer: Does one, who runs a newer PHP version such as 5.5, has to wait until a TSPHP translator component comes out which translates to PHP 5.5?

R. Stoll: In the ideal case I would say no. I
f PHP would really stick to semantic versioning than one does not require another translator component since the code which is generated for PHP 5.4 should be compatible with all versions upwards within the corresponding major version. 
One would need to wait for a translator 5.3 component tough if one runs a PHP 5.3 environment. However, I guess PHP 5.3 will already be obsolete (at least no longer supported) by the time TSPHP is really ready for production.

Interviewer: You said in the ideal case. How does the practical case look like?

R. Stoll: Well, I guess we all know that in the real world PHP does not maintain backwards compatibility in all cases and it might well be that some changes can not be adapted by TSPHP in order that the same code behaves the same way in different PHP versions. I like to think that TSPHP can provide some stability between different PHP versions but to be honest, I think that is not always possible. 

Interviewer: Could you please elaborate a bit. Why is it not possible? Do you see a concrete scenario where TSPHP fails?

R. Stoll: The why is quite simple, because TSPHP does not change PHP's core and thus can only cover cases where new features are implemented or changes are backwards compatible. For instance, the function password_hash which is new since PHP 5.5 and could be enabled in PHP 5.4 as well by reimplementing the function in PHP itself and add it to the output code of a PHP 5.4 project. That brings about the drawback that this implementation could also contain bugs next to the implementation written for PHP itself. It is easier to support syntactic sugar.

Interviewer: I will come back to this drawback later on. You have not yet given a scenario where TSPHP fails. Do you know one?

R. Stoll: No, I cannot think of a scenario at the moment but I am certain that backward compatibility breaks were introduced since PHP 5.0. At least, I would not want to run PHP 5.0 code in a PHP 5.5 environment. But might be that I have a wrong appraisal.

Interviewer: Fair enough, let us move on and have a look at assets given due to type safety.
What advantages does a statically typed, type-safe programming language bring about compared to a dynamically and weak typed one?

R. StollIn my personal opinion, TSPHP brings about the following advantages compared to PHP

  • Improved readability
  • Enables better static code analysis
  • Enables improved refactoring support
  • Enables improved code completion support
  • Certain bugs can be avoided such as
    • Wrong assignments
    • Wrong function/method calls (actual parameter missing or a wrong type is passed)
    • Missing return types
    • Wrong operator usage
    • and probably more

As a side notice, type safety as such does not mean that a language has to be statically typed. A dynamically typed language can still be type-safe in theory.

How does TSPHP improve readability?

R. Stoll: Just one example, it is clear at one glance what a function/method returns and what types it expects just by reading the definition.

Interviewer: But one could also just write a PHPDoc block as follows:

PHP code
 * @param Prduct $product
 * @param int $quantity
 * @return float the price
function getPrice($quantity, Product $product){

R. Stoll: Indeed, but why should you document something if you could express it in code directly?

Interviewer: Could you elaborate on this point, I do not get what you mean?

R. Stoll: Consider that your code changes over time but you forget to update your documentation (what is quite likely, it happens to me as well at least). In addition, your documentation could be wrong (see Prduct instead of Product above) and finally, no one controls if the user actually does return the correct type or pass the corresponding type.

Interviewer: I disagree, one can specify type hints in PHP to ensure type safety for parameters.

R. Stoll: That is true and wrong in the same time. It is true that you can specify type hints but, firstly, you cannot write type hints for scalar types so far and secondly, also if one does specify type hints, they are only binding for the call and not afterwards. Thus wrong assignments can still be made inside the function. There is nothing like type safety for parameters in PHP. Consider the following example:

PHP code
function getPrice($quantity, Product $product){
   $product = 1; // valid assignment in PHP

Why does TSPHP enable better static code analysis?

R. Stoll: Because static code analysis can now include type information as well. That is of course an advantage.

Why does TSPHP enable improved refactoring support?

R. Stoll: Because the statically typed aspect of the language enables a refactoring algorithm to perform automatically in most cases whereas the current refactoring support for PHP needs always a confirmation from the user. I have also seen that suggestions made by current refactoring algorithms are sometimes wrong and the user has to go through each suggestions to be sure that he/she does not introduce a new bug. Furthermore, the type safety aspects ensures that situations as the following, which cannot be dealt with by refactoring algorithms, cannot occur:

PHP code
class Foo {
    function foo(){}
class Bar {
    function foo(){}
$o = new Foo();
  $o = new Bar();

If code like this exists somewhere in your code base and you are going to rename the method foo in one of those classes then the refactoring algorithm will either suggest to rename foo in line 11 as well or not and both is wrong. 

How does TSPHP enable improved code completion functionalities?

R. Stoll: Since an IDE knows at each point in code what type a variable has, it can suggest the code completions accordingly.

Interviewer: But one can give hints to the IDE by providing vardoc's as follows:

PHP code
/* @var $o Foo*/
$o->foo(); //foo will be suggested by the IDE due to the vardoc

R. Stoll: Absolutely, one can already provide additional type information in PHP. Yet, I will use the same argument as before about documenting parameters: why document it when you can express it in code directly? Besides, if one puts vardoc and phpdoc all over the code then one probably already code in a type-safe manner but without the additional check of the compiler.

Interviewer: True, we have already discussed a similar topic (please have a look at How does TSPHP improve readability?).
Nevertheless, I would like to discuss one aspect of your statement which we have not yet covered. You said, one does already code in a type-safe manner if one uses vardoc and phpdoc. So why would one want to switch to TSPHP if one can already code in a type-safe manner in PHP?

R. Stoll: If I would need to say it in one sentence then I would say:

trust is good, control is better.

In my understanding, type safety is pretty much a helping hand for quality assurance. I would claim people use vardoc mainly because the IDE can support the user better this way. The same goes for phpdoc whereat it is also used for documenting purposes of course. What does users have to ask themselves is: Do I already write in a type-safe manner all the time? Do I want to breach type safety from time to time? If you do not have the need to breach type safety then I would highly recommend to switch to TSPHP which will ensure that you will not breach type safety inadvertently. And if you should have the need to breach type safety later on then you can still use the output code which is PHP in a purely PHP project and get wild again (smile)

: We were only talking about assets so far but there are certainly drawbacks as well.

Drawbacks of TSPHP

R. Stoll: TSPHP has drawbacks as well of course. I can elaborate on the points as usual:

  • an additional step in the development process is needed
  • increased complexity due to type safety
  • Current PHP code cannot be used directly in TSPHP
  • TSPHP cannot support all features of PHP
  • TSPHP needs to be maintained in parallel to PHP
  • TSPHP has currently no tools or frameworks
  • TSPHP requires a new development environment

Interviewer: Please elaborate on the first point...

An additional step in the development process is needed

R. Stoll: I think it is almost needless to say that the compilation process as such is a drawback and can hinder the development process.
PHP users are used to edit code -> press F5 in the browser -> watch the result -> edit code -> etc. Suddenly they have to do additionally a step, namely compile the code. So the cycle would be: edit code -> compile it -> press F5 in the browser -> watch the result -> edit code -> etc.

Interviewer: What does one have to expect if you say the additional step can hinder the development process?

R. Stoll: I would say, TSPHP is quite lucky that there is not a further step in each cycle like running a server as in ASP.NET. Hence, depending on how fast the compilation process will be, it will not bother the user at all or a bit. That said, performance optimisation of the compiler itself are not yet done. As a side notice, I want that many people can contribute to the project and thus favour simplicity over performance right now.

But to give an answer to your question, I do not know yet how much time the additional compilation step will cost and I am pretty sure that this can be optimised further by incremental compilation and such. A good IDE support will be required too to ease the development with TSPHP.

What is meant by 'increased complexity due to type safety'?

R. Stoll: This might sound ridiculous to users which have experience with type safety already. For all others it is an additional complexity and especially for beginners this might be a barrier. I would suggest that beginners start with PHP first and then move on to TSPHP if they want type safety.

Interviewer: Sounds like you put PHP down as programming language for beginners.

R. Stoll: Far from it, you got me wrong. You can do incredible things with PHP and it is certainly not just a toy language. All I say is that PHP disburden the user from type safety and thus is easier to learn. As soon as one realise that type safety is not a burden but a useful feature then one should switch to TSPHP. 

Interviewer: And what if one sees the benefits of type safety but does not want it?

R. Stoll: Well, then one can stick to PHP. TSPHP does not try to change PHP (see What is the vision of TSPHP?). 

Interviewer: All right, let us move on to the next point... 

Current PHP code cannot be used directly in TSPHP

R. Stoll: That is right and that is certainly a drawback. I am thinking of introducing something like unmanaged code where one can also include PHP code but it is not yet concrete and I am not sure if it would be a good idea because it would require a lot more runtime checks which would slow down the whole TSPHP. 

I would rather say TSPHP is not going to support the reuse of PHP code in TSPHP directly. 

Interviewer: Fair enough, maybe we can cover this point in another interview.

Why can TSPHP not support all features of PHP?

R. Stoll: The question should be "does TSPHP want to support all features?" and TSPHP certainly does not want to support all features (see Not Supported above). Yet, some features might be too dynamic and TSPHP is not able to support them fully or not in the same way as PHP does. 

Interviewer: Can you please give an example of such a feature which TSPHP is
 not able to support fully?

R. Stoll: Magic functions for instance. We have discussed it before, so I am not going into details here (see Does TSPHP support magic functions like __get and __set?).

Interviewer: There are still quite a lot of features which are not yet implemented (see Scope, will change though). This goes along very well with your next point... 

TSPHP needs to be maintained in parallel to PHP

R. Stoll: This could certainly be seen as a huge drawback but in my opinion it is not and rather inevitable if TSPHP shall coexist next to PHP. I believe this will not be a drawback if enough people like the idea of TSPHP and contribute to the project.

Interviewer: Right, but code is not the only thing which needs to be maintained in parallel. Also tools and frameworks and...

TSPHP has currently no tools or frameworks

R. Stoll: That is actually one of the biggest drawbacks TSPHP has to cope with and I am aware of that most people will propably not use TSPHP if they cannot reuse their favourite framework or CMS. TSPHP has a project in the pipeline which tries to address this problem but it is to soon to say more about it.

At the moment, one either has to write everything on his/her own until there will be TSPHP frameworks available or one can write modules in TSPHP and reuse them in purely PHP projects. 

Interviewer: I think it is quite illusive to think that one can write modules in TSPHP for a certain framework without using fragments of the framework itself.

R. Stoll: That is certainly true and as I said TSPHP has a project in the pipeline which tries to address this problem. I can say as much as the project tries to convert PHP code in TSPHP code. If that should work properly than TSPHP will have frameworks after all. Until then I encourage everyone, who actually like the idea of TSPHP, to contribute to the project in a way (providing feedback, correct my grammar mistakes (wink) and of course; implement features, fix bugs and so on).

The project is still in its early stage and needs commitment to evolve. Frameworks are not the only thing which are missing. An IDE which supports TSPHP fully is another thing.

Interviewer: I would like to come back to this point later on. I am not sure if I got the last point of your list right, just to be sure

Why does TSPHP require a new development environment?

R. Stoll: Well, most of it is actually covered in the previous point but I want to stress that TSPHP does not have any tools right now. If one uses a PHP-IDE then one will be disappointed that there is no support for TSPHP right now. If you are using an editor with enhanced syntax support for PHP then you might come off very well and you do not need to change anything. 

 Nevertheless, I want to point out an addition which is not covered in the previous point; one needs Java installed on his machine because the TSPHP compiler is implemented in Java.

Interviewer: Ok, this brings me to another point...

Does TSPHP require an own runtime environment?

R. Stoll: No it does not. TSPHP does not require an own runtime environment because TSPHP is translated back to PHP (see the picture above). Sometimes I like to think that TSPHP is kind of a very big DSL for PHP where the Domain stands for type safety. You could also think of TSPHP is compiled to some kind of byte code named PHP which is then interpreted by the virtual machine PHP. Of course that is just figurative and PHP code is not really byte code and PHP itself not a virtual machine.

So in contrast to Facebook's project HHVM, TSPHP does not require a new runtime environment which can be costly.

Interviewer: Yet, you said before and I also read in your Bachelor Thesis - Type-Safe PHP: A compile time approach that the compiler is implemented in Java. Thus I assume a TSPHP user needs a Java runtime environment, doesn't one?

R. Stoll: You have got me there (smile) but as you already mentioned, I actually said that one requires a Java environment in order to be able to run the compiler.
To conclude, I would say TSPHP requires a new development environment but does not require a new runtime environment (see point above).

Why is the TSPHP compiler implemented in Java and not in PHP?

R. Stoll: There are actually several reasons but the two main one are:

  • PHP does not support multi-threading and thus is too slow. There is an extension which shall enable multi-threading but I need it in the core in order that the normal PHP user can use it.
  • Compiler generator such as ANTLR (which TSPHP is using) or flex/bisson (which PHP is using) usually do not generate the output in PHP.

Interviewer: Is there a goal to port the compiler to PHP one day?

R. Stoll: No, at least not directly. If I port it then I would port it to TSPHP. But of course, since TSPHP is translated to PHP it would also be available in PHP just with an indirection. But first of all, I would need to port ANTLR to TSPHP and that is a project on its own.

Interviewer: But why did you choose Java and not C# or another programming language?

R. Stoll: My decision was based on the fact that the most popular IDE's for PHP are based on Java and thus the chances are high that a PHP user has already installed Java. Another aspect was of course the portability of Java. But to be fair, I do not really know how advanced is Mono for .NET

Nevertheless, I was thinking about portability when I was implementing the compiler and therefore also chose ANTLR over flex/bison because ANTLR does already generate output in quite a few programming languages. Thus a port of the compiler should be easier. I also tried to avoid to clutter the the grammar and tree-parse-grammar files with code to ease a port.

Interviewer: Sounds a little bit like you already have plans to port it to another language. Do you?

R. Stoll: I did not have any plans when I started the project neither when I decided to go for Java but in the meantime I have met Filip Wojcieszyn which is one of the founders of the awesome project scriptcs and I kind of like the idea to write a TSPHP engine for scriptcs one day (smile)

Does TSPHP compete against Facebook's HHVM, Hack respectively?

R. Stoll: It does probably indirectly but TSPHP does not want to compete against HHVM, Hack respectively. Contrariwise, I think there are some opportunities where the two projects could benefit from each other. 

Interviewer: How?

R. Stoll: Facebook has lately published their way of enhancing PHP with additional type hints. They call the new language Hack. I have not tried out Hack yet (because I lack of an Ubuntu installation right now) and thus do not know how well it is implemented and how they treat crucial points such as reflection, serialisation/deserialisation etc.). Anyway, the enhanced syntax of Hack points in the direction of type safety. Hack is gradually typed (their terminology) which means you can add more type hints but it is not necessary. In contrast to TSPHP which is type-safe and enforces the additional type definitions. Nevertheless, they have both in common that they try to make PHP users aware of the benefits of type-safe code. 

Interviewer: How else do the projects benefit from each other apart from sharing the spirit of enhancing type safety in PHP?

R. Stoll: One thing Facebook could learn from TSPHP is that a translation back to PHP is a good idea. If a user uses the enhanced syntax of Hack then he/she lose somewhat the forward compatibility to PHP, the user cannot reuse the code in its normal PHP projects respectively. That is a huge drawback and I for myself would think about it very carefully before using the enhanced syntax of Hack even though I am aware of that the additional type hints might result in a better performance. I would be careful because I cannot reuse the code in a purely PHP project (where the runtime environment for Hack, HHVM respectively, is not installed).

On the other hand, TSPHP could benefit from the performance enhancements Facebook has already implemented. Since TSPHP is designed in a modular way it would be quite easy to implement a new translator which translates TSPHP to the Hack. It would also be possible to translate TSPHP directly into HHVM's bytecode and thus would even be faster than Hack which has to be parsed first, type infererence and type checking is necessary etc. Sure, translating to byte code would be more complex than translating to Hack but absolutely doable.

Last but not least, TSPHP has another project in the pipeline and Facebook could benefit from it as well. I mentioned it before and it is about converting PHP code to TSPHP code. Yet, the project is not yet official and I cannot give more information about it at this stage.  

What are the differences between TSPHP and Hack?

R. Stoll: I pointed a few out in the previous question but like to sum up here and compare TSPHP and Hack. I am not really familiar with hack and I have left some cells with a question mark where I am not sure how Hack behaves. If you should know more then please let me know (smile)

Type-safetyduring compile timeoptional 
Runtime environmentsame as PHPnew runtime environment 
Development environmentneeds Java to compileCan be written in a normal text editor.
If the user uses an IDE then it most
likely does not support Hack (the
enhanced syntax)
variable declarationtype $atype $a 
function definitionfunction void foo(){}function foo() : void {} 
Nullabletype? $a?type $a 
Falseabletype! $anot (yet) supported 
Type which can hold all typesmixedmixed


Tuplesnot yet supported(int, bool, X)

see return-false-if-something-goes-wrong approach
Tuples in the sense of Hack (a type which can hold
several types) goes against the Vision of TSPHP

This would still be against the vision but I misinterpreted
tuples in Hack. They are really tuples (a collection) and
not a type which can hold several types. Such tuples
might well be introduced in TSPHP as well in the future.

Closuresint callable(int)(function(int): int)TSPHP does not yet support
those concepts, but the presented
syntax is most likely how it will
look like in TSPHP.


T foo<T>(T $x)

foo<T>(T $x) : T 

ConstraintsT foo<T as A>(T $x)foo<T as A>(T $x): T
namespacesnamespace t;namespace t; 
cast to class/interface(Type)not yet supported 
cast modifiercast int $a;not (yet) supported 
Casting Operatorint $a =() 1.2;not (yet) supported 
Identifier case sensitive?yes? 
Field initialisation of scalar typesautomatically:
//$a will be 1 
class A{int $a;}
Check implemented which
does not cover all cases.
Field can be null in some cases
Question about field initialisation
was asked in a presentation of HHVM.

When will the version 1.0.0 of TSPHP come out?

R. Stoll: This will take some time and as long as I am the only contributor this will certainly not be before the beginning of 2017 ^^ 

Interviewer: in 3 years! you must be kidding, isn't it? Why should one even care about TSPHP if it takes so long?

R. Stoll: That is my point, if no one else cares then it will take so long (or even longer). If others care about the project and contribute to the project then v. 1.0.0 might be out in 2016 or even in 2015. Thus I hope there are actually other people out there which like the idea of TSPHP and support the project. See, I am not employed by anybody to contribute to this project and I spend quite a bit of my free time to contribute to this project.

What will be included in 1.0.0?

R. Stoll: v. 1.0.0 shall cover more or less all features of PHP (excluding features which are not wanted in TSPHP) and shall include generics and typed arrays additionally.

Interviewer: New features are implemented in PHP with every version, is v. 1.0.0 going to include those features as well?

R. Stoll: Hard to say since I do not know what new features will be implemented in the future. There will certainly be features which TSPHP will not yet support and others which will be supported and maybe even some features will be implemented in TSPHP which have been rejected in PHP. 

Is TSPHP using semantic versioning?

R. Stoll: TSPHP is somewhat in experimental mode and cannot guarantee for backward compatibility up to v. 1.0.0. After releasing v. 1.0.0 it will stick to semantic versioning.

Yet, since TSPHP relies on PHP it cannot guarantee for any backward compatibility breaks introduced in PHP itself. 

How can others contribute to the project?

R. Stoll: There are a few ways how one can contribute to the project:

  1. Providing feedback to the topics mentioned in the page Not yet implemented
  2. Asking questions about TSPHP (write an email to
  3. Try out TSPHP and provide feedback -> latest demo client can be found on the build server (
  4. Improve the Language Reference Manual or other wiki pages (for instance this interview) by
    1. Adding further examples
    2. Correct my grammar mistakes (I am not a native speaker as you have surely noticed)
    3. etc.
  5. By implementing/fixing issues -> have a look at the issue tracking system and the version control system (github)
  6. Reporting bugs and submit feature/change requests
  7. Write about TSPHP in your own blog (might encourage others to contribute to the project)
  8. Post a link on facebook, twitter, google+ and co.
  9. Speak about TSPHP with your colleagues (might encourage others as well)
  10. Are you an undergraduate or postgraduate student and are looking for a topic for your thesis? I have some interesting topics for you (wink)
  11. Donations are welcome as well of course. However, I have not opened a bank account for TSPHP yet so please contact me first.
  12. I am sure you have further ideas (if so, let me know (smile))

Please have a look at Contribute to the project for more information.
In all cases, if you wish help or have further questions, do not hesitate to contact me directly (

Interviewer: All right, thank you very much for your time and I hope the project will find other contributors

R. Stoll: Thank you for having me

  • No labels