I really would like to finalize this issue ASAP because it's the last *feature* I see for PHP 5.0. The main reason why I think we need to finalize it is because depending on the solution we choose, it would break BC if we fix it after 5.0.
Consider the following options for a parameter with default value which allows null:
MyClass $a or NULL = 5
MyClass $a = 5 or NULL
MyClass or NULL $a = 5


I think all of these are pretty ugly and I don't feel comfortable with adding them to the language.
The following (Zeev's idea) is much simpler and nicer, but I'm not 100% sure if this is the perfect solution:
nullable MyClass $a = 5


Ideas/comments?

Andi

At 07:17 PM 5/2/2004 +0200, Marcus Boerger wrote:
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


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



Reply via email to