technical issues in type hinting patch are not as big of an issue as it appears View as Markdown

Hi,

It is important to realize that the sole question here is what kind of
type hinting to implement. Any technical problems can be resolved with
some trade-offs.

There are a couple of approaches that come to mind.

1. make all type hints slightly slower (double lexing, once as T_STRING,
   and then again)

use T_STRING for type hints, so that "int/bool/etc." do not become new
reserved words, and do the lexing at parse-time. In addition, now that
we have namespaces, it is possible to definitively distinguish between a
true int type hint and an "int" class type hint:

function (\int $integerObject) {}
function (int $actualInteger) {}

This kind of "double lexing" is already performed to detect the "parent"
keyword in several places, as this is not a reserved word in PHP, so the
hit is not so bad.

The tradeoffs here are:

• double scanning of T_STRINGs in type hints at parse-time (no extra
  performance hit beyond the run-time type verification for users of
  opcode caches)
• potential confusion when suddenly methods with existing type hints
  matching "int" and company start complaining about arguments not being
  integers.

2. use cast syntax

function (int $integerObject) {}
function ((int) $actualInteger) {}

The tradeoff here is an intellectual one: (int) means something
different in a method signature than what it means in regular PHP code.

3. introduce a new syntax for scalar type hints

function (int! $actualInteger) {}

the drawback here is that it adds to the learning curve to learn what
int! means (and why it is so excited :)

All of these examples are just to say that there is no technical issue
that can't be solved with some kind of tradeoff, the main question is to
decide what kind of type hinting to implement, strict/casting/something
in between.

Greg