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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
