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

- Thread: https://externals.io/message/44872
- Original archive: https://news-web.php.net/php.internals/44872
- Started by Greg Beaver on 2009-07-09T15:03:36+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #44872 — Greg Beaver — 2009-07-09T15:03:36+00:00

URL: https://externals.io/message/44872#44872

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

---

## #44880 — Stanislav Malyshev — 2009-07-09T19:15:30+00:00

URL: https://externals.io/message/44872#44880 · In reply to: #44872

Hi!

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

Actually, it means pretty much the same - conversion to int type.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #44881 — Greg Beaver — 2009-07-09T19:18:23+00:00

URL: https://externals.io/message/44872#44881 · In reply to: #44880

Stanislav Malyshev wrote:
> Hi!
>
> > […]
>
> Actually, it means pretty much the same - conversion to int type.
Hi,

You assume that cast type hinting will be the implementation chosen.  If
the type hinting is in fact validation the way object type hinting is
(strict type hinting), no conversion takes place, and the meaning is
different.  I should have said "if strict type hinting is implemented"
in the drawback description to make that clear.

Greg

---

## #44882 — Stanislav Malyshev — 2009-07-09T19:22:05+00:00

URL: https://externals.io/message/44872#44882 · In reply to: #44881

Hi!

> You assume that cast type hinting will be the implementation chosen.  If
> the type hinting is in fact validation the way object type hinting is
> (strict type hinting), no conversion takes place, and the meaning is
> different.  I should have said "if strict type hinting is implemented"
> in the drawback description to make that clear.

If there's only strict typing, there's no reason to make it's syntax to 
be resembling typecasts.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com