# [RFC] Type hints

- Thread: https://externals.io/message/9623
- Original archive: https://news-web.php.net/php.internals/9623
- Started by Marcus Boerger on 2004-05-01T20:09:32+00:00
- Messages: 10
- 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

---

## #9623 — Marcus Boerger — 2004-05-01T20:09:32+00:00

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

Hello internals,

  while working with php 5 the last days i find it more and more
annoying that we allow `NULL` with type hints. From my perspective
allowing `NULL` with typehints would happen only very rare. So i
looked into the issue once again and prepared a patch.

  first i looked back the mails for this issue and found three
possible solutions:

1) (Zeev) allow `NULL` only when it is the first default argument.
Here the disadvantage is that you cannot have non default parameters
after one that allows NULL. Also this would introduce a BC break if
we'd go this way after 5.0 is out because it changes the standard
behavior.

2) (Andi) introduce 'not null' after php 5.0. This won't introduce
a BC break. But it would require two new keywords 'NOT' and 'NULL'.
The latter is not a problem because it is a define at the moment
and the patch (a) shows that it easy to change it into a keyword.
The problem is the new keyword 'not' which would introduce a BC
break for everyone using the word 'not' already.

3) (Myself) introduce 'or null'. Obviously this would introduce a
BC break when implemented after PHP 5.0 is out. The advantage is
that it only requires `NULL` as an additional keyword (see above)
and that it reflects the code it replaces. The replacement code
is to check whether the parameter is an instance of the typehint
"or" if specified check if it is null:

func(Classname or `NULL` $param) {}

replaces

func($param) {
  if ($param instanceof Classname or is_null($param)) {
     // ok
  } else {
    // error
  }
}

Having listed the three ideas i think we must address this issue
now and cannot delay it until after php 5.0 is out. Because of
2's additional keyword and 1's disadvantage i like 3 most. The
patch (b) implements it and adds a testfile.

Patch (c) also implements typehints for 'array' and 'class'.
Array checks the parameter for being an array and class checks
the parameter to be an instance of any class. These two we
agreed to do already and so i added an updated patch for it
which also includes the 'or null'.

(a) http://somabo.de/php/ext/ze2/ze2-null-patch-20040501.diff.txt
(b) http://somabo.de/php/ext/ze2/ze2-type-hints-null-20040501.diff.txt
(c) http://somabo.de/php/ext/ze2/ze2-type-hints-20040501.diff.txt

p.s.: As a sideeffect these patches speedup `NULL` handling.

Best regards,
 Marcus

---

## #9624 — Michael Walter — 2004-05-01T20:27:51+00:00

URL: https://externals.io/message/9623#9624 · In reply to: #9623

Marcus Boerger wrote:
> Hello internals,
 > [...]
How about
   function foo(Class? bar)
instead? Too much magic?

Cheers,
Michael

---

## #9625 — Derick Rethans — 2004-05-01T20:52:05+00:00

URL: https://externals.io/message/9623#9625 · In reply to: #9624

> Marcus Boerger wrote:
> > […]
> How about
>    function foo(Class? bar)
> instead? Too much magic?

Too much magic indeed.

Derick

---

## #9626 — John Coggeshall — 2004-05-01T21:27:32+00:00

URL: https://externals.io/message/9623#9626 · In reply to: #9623

I agree with the idea that it would be nice to force an instance of a
particular class, etc. to be passed. However, if we are going to
introduce another keyword anyway why not keep BC intact by by
introducing the 'force' keyword:

function myfunction(force ClassName $param, NextClass $another) {

}

Where 'force' would prevent $param from being passed as anything but an
acceptable ClassName. Alternatively, for the sake of parsing you could
do:

function myfunction(Classname forced $foo) {

}

I remember discussing 'array' as a typehint (big +1 there), but I don't
see anything gained from such a type-hint. When exactly would you use it
(that you couldn't use the existing type hinting).. I guess the obvious
answer is when you don't know the type of class being passed, but if you
don't know that how do you plan on actually using the parameter at all? 

John

-- 
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall                   http://www.coggeshall.org/
The PHP Developer's Handbook    http://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=

---

## #9627 — Marcus Boerger — 2004-05-01T22:05:23+00:00

URL: https://externals.io/message/9623#9627 · In reply to: #9626

Hello John,

Saturday, May 1, 2004, 11:27:32 PM, you wrote:

> I agree with the idea that it would be nice to force an instance of a
> particular class, etc. to be passed. However, if we are going to
> introduce another keyword anyway why not keep BC intact by by
> introducing the 'force' keyword:

the point of solution 3 was not to introduce a new keyword other than null.
And adding null as a keyword dosn't have implications other that ppl may
have a fucntion called 'null'. But i don't think that happens often. Using
force or forced on the other hand seems to happen often at least i used it
myself.

> I remember discussing 'array' as a typehint (big +1 there),

good so far

> but I don't
> see anything gained from such a type-hint. When exactly would you use it
> (that you couldn't use the existing type hinting).. I guess the obvious
> answer is when you don't know the type of class being passed, but if you
> don't know that how do you plan on actually using the parameter at all? 

What are you speaking of here?
array means the parameter must be an array.
class means the parameter must be any class instance which can be used for
reflection as an example.


Best regards,
 Marcus

---

## #9631 — Andi Gutmans — 2004-05-02T16:09:22+00:00

URL: https://externals.io/message/9623#9631 · In reply to: #9623

Hi Marcus,

It probably makes sense to go with (3) because as Zeev says, the majority 
of the times you don't want to allow NULL.
If we decide to go this direction we definitely need to implement it before 
PHP 5 because otherwise it'll be a big BC break.
I wouldn't use the syntax you proposed but you:
function func(MyClass $obj or null);

Concerning type hints, I don't think that a type hint of "class" is useful. 
If you don't use a base class as a type hint (which you will almost always 
use) then how useful will this really be? Also, it's not really Class but 
it's an Object, so we'd have to add another reserved word. In my opinion, 
I'd only go with the "array" part of the typehints patch.

On another note, I think PHP 5 is already stable and quite mature. It's an 
order of magnitude more stable than PHP 4 was when it was released. I think 
we should start thinking of a deep feature freeze and a release date. As 
we're in the beginning of May I think sometime towards July makes sense. 
This does mean that we really need to stop adding stuff. I agree to open 
the typehints issue because it could potentially lead to a BC break 
depending what solution we take.

Andi

At 10:09 PM 5/1/2004 +0200, Marcus Boerger wrote:
>Hello internals,
>
>   while working with php 5 the last days i find it more and more
>annoying that we allow `NULL` with type hints. From my perspective
>allowing `NULL` with typehints would happen only very rare. So i
>looked into the issue once again and prepared a patch.
>
>   first i looked back the mails for this issue and found three
>possible solutions:
>
>1) (Zeev) allow `NULL` only when it is the first default argument.
>Here the disadvantage is that you cannot have non default parameters
>after one that allows NULL. Also this would introduce a BC break if
>we'd go this way after 5.0 is out because it changes the standard
>behavior.
>
>2) (Andi) introduce 'not null' after php 5.0. This won't introduce
>a BC break. But it would require two new keywords 'NOT' and 'NULL'.
>The latter is not a problem because it is a define at the moment
>and the patch (a) shows that it easy to change it into a keyword.
>The problem is the new keyword 'not' which would introduce a BC
>break for everyone using the word 'not' already.
>
>3) (Myself) introduce 'or null'. Obviously this would introduce a
>BC break when implemented after PHP 5.0 is out. The advantage is
>that it only requires `NULL` as an additional keyword (see above)
>and that it reflects the code it replaces. The replacement code
>is to check whether the parameter is an instance of the typehint
>"or" if specified check if it is null:
>
>func(Classname or `NULL` $param) {}
>
>replaces
>
>func($param) {
>   if ($param instanceof Classname or is_null($param)) {
>      // ok
>   } else {
>     // error
>   }
>}
>
>Having listed the three ideas i think we must address this issue
>now and cannot delay it until after php 5.0 is out. Because of
>2's additional keyword and 1's disadvantage i like 3 most. The
>patch (b) implements it and adds a testfile.
>
>Patch (c) also implements typehints for 'array' and 'class'.
>Array checks the parameter for being an array and class checks
>the parameter to be an instance of any class. These two we
>agreed to do already and so i added an updated patch for it
>which also includes the 'or null'.
>
>(a) http://somabo.de/php/ext/ze2/ze2-null-patch-20040501.diff.txt
>(b) http://somabo.de/php/ext/ze2/ze2-type-hints-null-20040501.diff.txt
>(c) http://somabo.de/php/ext/ze2/ze2-type-hints-20040501.diff.txt
>
>p.s.: As a sideeffect these patches speedup `NULL` handling.
>
>Best regards,
>  Marcus

---

## #9632 — Timm Friebe — 2004-05-02T16:39:21+00:00

URL: https://externals.io/message/9623#9632 · In reply to: #9623

> Hello internals,
> 
>   while working with php 5 the last days i find it more and more
> annoying that we allow `NULL` with type hints.
> From my perspective allowing `NULL` with typehints would happen 
> only very rare.

I don't think this is true. I think there are a number of cases where
passing `NULL` is used to "unset" or "delete" something. For example, say
a class supports debugging using a listener model:

  class Foo {
    function setEventListener(Listener $l) { ... }
  }

  $foo= new Foo();
  $foo->setEventListener(new ConsoleListener());
  // ...
  $foo->setEventListener(NULL);

This makes perfect sense to me and also gets rid of the constraint of
having to define an "unsetEventListener" method.

To wrap it up: Would you agree that being able to pass `NULL` to any
pointer argument in C is annoying?

[...]
> 2) (Andi) introduce 'not null' after php 5.0. This won't introduce
> a BC break. But it would require two new keywords 'NOT' and 'NULL'.
> The latter is not a problem because it is a define at the moment
> and the patch (a) shows that it easy to change it into a keyword.
> The problem is the new keyword 'not' which would introduce a BC
> break for everyone using the word 'not' already.

I like this idea best: No magic such as "only when it is the first
default argument" (the question "why" will inevitably come up sooner or
later); plus no BC break.

Concerning the new keyword argument, how about using the exclamation
mark (already meaning "not"), as in:

* function foo(Classname !NULL $val) { }
  The same as Andi's suggestion, but using ! instead of "not"

* function foo(Classname $val !NULL) { }
  Ditto, but using postfix notation. Comes close to default value
  syntax which people are already used to.

* function foo(Classname $val != NULL) { }
  This would be even more similar to the default value syntax.

- Timm

---

## #9634 — Timm Friebe — 2004-05-02T17:00:04+00:00

URL: https://externals.io/message/9623#9634 · In reply to: #9623

> Hello internals,
[...]

While thinking about this for a while and playing around with different
notations, I stumbled across the following:

  function foo(Foo $f = 1) { }

This will actually "compile" (but never work). It doesn't make any sense
anyway. In my opinion, this should give an E_COMPILE_ERROR.

- Timm

---

## #9633 — Andi Gutmans — 2004-05-02T17:00:26+00:00

URL: https://externals.io/message/9623#9633 · In reply to: #9623

At 06:39 PM 5/2/2004 +0200, Timm Friebe wrote:
>
> > […]
>
>I don't think this is true. I think there are a number of cases where
>passing `NULL` is used to "unset" or "delete" something. For example, say
>a class supports debugging using a listener model:
>
>   class Foo {
>     function setEventListener(Listener $l) { ... }
>   }
>
>   $foo= new Foo();
>   $foo->setEventListener(new ConsoleListener());
>   // ...
>   $foo->setEventListener(NULL);
>
>This makes perfect sense to me and also gets rid of the constraint of
>having to define an "unsetEventListener" method.
>
>To wrap it up: Would you agree that being able to pass `NULL` to any
>pointer argument in C is annoying?

Personally, I would leave things the way they are today. But both Zeev and 
Marcus feel this is the wrong way to go and I understand their point.


>[...]
> > […]
>
>I like this idea best: No magic such as "only when it is the first
>default argument" (the question "why" will inevitably come up sooner or
>later); plus no BC break.
>
>Concerning the new keyword argument, how about using the exclamation
>mark (already meaning "not"), as in:
>
>* function foo(Classname !NULL $val) { }
>   The same as Andi's suggestion, but using ! instead of "not"
>
>* function foo(Classname $val !NULL) { }
>   Ditto, but using postfix notation. Comes close to default value
>   syntax which people are already used to.
>
>* function foo(Classname $val != NULL) { }
>   This would be even more similar to the default value syntax.


I prefer "not null" :)

Andi

---

## #9635 — Marcus Boerger — 2004-05-02T17:17:32+00:00

URL: https://externals.io/message/9623#9635 · In reply to: #9631

Hello Andi,

Sunday, May 2, 2004, 6:09:22 PM, you wrote:

> Hi Marcus,

> I wouldn't use the syntax you proposed but you:
> function func(MyClass $obj or null);

an updated patch can be found here:
http://somabo.de/php/ext/ze2/ze2-type-hints-20040502.diff.txt


> Concerning type hints, I don't think that a type hint of "class" is useful.
> If you don't use a base class as a type hint (which you will almost always
> use) then how useful will this really be? Also, it's not really Class but 
> it's an Object, so we'd have to add another reserved word. In my opinion, 
> I'd only go with the "array" part of the typehints patch.
the updated patch neither contain 'class' not 'object'. Adding Object as a
reserved work is a bad ide imo because i thing many ppl use it for basic
classes. The reasons i chose class in the first place were that i didn't
want to add a new keyword and that i had the term 'instance of any class'
in mind.

> On another note, I think PHP 5 is already stable and quite mature. It's an
> order of magnitude more stable than PHP 4 was when it was released. I think
> we should start thinking of a deep feature freeze and a release date. As 
> we're in the beginning of May I think sometime towards July makes sense. 
> This does mean that we really need to stop adding stuff. I agree to open 
> the typehints issue because it could potentially lead to a BC break 
> depending what solution we take.
more or less agreed. what i fear is missing the chance to act on bad test
experience. but we can't wait forever, so how about a branch now, that
could attract even more testers and hence give more feedback?

best regards
marcus