[RFC] Type hints

Marcus Boerger wrote:

Hello internals,
[...]
How about
function foo(Class? bar)
instead? Too much magic?

Cheers,
Michael

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/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=

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

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

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

At 06:39 PM 5/2/2004 +0200, Timm Friebe 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.

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.

[...]

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.

I prefer "not null" :)

Andi