Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14699
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <5.1.0.14.2.20041027094918.02e53c80@localhost>
References: <15784920.20041027092711@marcus-boerger.de> <20041022174124.27478.qmail@pb1.pair.com> <20041027002106.94528.qmail@pb1.pair.com> <15784920.20041027092711@marcus-boerger.de> <5.1.0.14.2.20041027094918.02e53c80@localhost>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <379e58b4e598e63027731ebddfd92e8e@bellsouth.net>
Content-Transfer-Encoding: 7bit
Date: Mon, 7 Feb 2005 15:40:49 -0500
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Type hints with null default values
From: lingwitt@bellsouth.net

What was the result of this discussion?

Thanks

On 27 Oct 2004, at 12:50, Andi Gutmans wrote:

> At 10:53 AM 10/27/2004 +0200, Christian Schneider wrote:
>> Marcus Boerger wrote:
>>> So for now the only addition we may probably consider for 5.1 is
>>> adding 4: optional typehinted values that default to null and only
>>> null.
>>
>> Please don't add another parameter syntax (especially with 
>> line-noi... err special characters) like [BaseClass]. This would make 
>> PHP more unreadable than it needs to be for a minor feature. To allow 
>> foo(BaseClass $objA = null) to also accept foo(null); handles the few 
>> cases where you want to pass null nicely IMHO.
>>
>> Advocating to only change the PHP syntax to simplify it,
>
> Yeah I tend to agree. Adding [] for a not that popular case seems not 
> to be worth it. It just adds more complexity to the syntax.
> I suggest to either leave as is or to support default values of NULL 
> (only) and if that is given then you may also pass NULL (give it a 
> double meaning).