Re: [RFC] Type hints

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