Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48421
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain moonspot.net designates 72.5.90.27 as permitted sender)
Message-ID: <4BFA18D6.5030209@moonspot.net>
Date: Mon, 24 May 2010 01:12:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Ilia Alshanetsky <ilia@prohost.org>
CC: Ralph Schindler <ralph@smashlabs.com>, 
 internals <internals@lists.php.net>
References: <4BF6A90D.8020901@smashlabs.com> <4BF6AD07.7090001@moonspot.net> <AANLkTilyZUdos7iUfPaAgvN89g1m4Gf9A1_4gXyBjQPu@mail.gmail.com>
In-Reply-To: <AANLkTilyZUdos7iUfPaAgvN89g1m4Gf9A1_4gXyBjQPu@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Fixes for parse_url, bug 50563
From: brian@moonspot.net (Brian Moon)

Because that is, IMO, a bad precedent to start for PHP internal 
functions. Too many functions already produce warnings (fopen) and 
return a status that can be checked. The solution right now is @ and 
that has so much baggage with it that you can now disable that feature 
completely making distributed software not be able to deal with these 
functions and return useful messages instead of spewing warnings 
uncontrollably. I am all for turning off warnings when a function 
returns a success/failure status.

Brian.
--------
http://brian.moonspot.net/

On 5/22/10 9:42 AM, Ilia Alshanetsky wrote:
> Instead of removing a warning, why not add an additional parameter to the
> function that would instruct it to silence warning messages on parse
> failure?
>
> On Fri, May 21, 2010 at 11:55 AM, Brian Moon<brian@moonspot.net>  wrote:
>
>> +1
>>
>>
>> Brian.
>> --------
>> http://brian.moonspot.net/
>>
>>
>> On 5/21/10 10:38 AM, Ralph Schindler wrote:
>>
>>>
>>> Hey all,
>>>
>>> Attached is a patch to remove the warning from parse_url() in situations
>>> where parse_url() cannot actually parse the url. The bug report also
>>> claims there should be a new feature for understanding "why" a parsed
>>> url failed. That code currently does not exist, and the current warning
>>> gives no more information than simply returning false does.
>>>
>>> http://bugs.php.net/bug.php?id=50563
>>>
>>> The first patch is against trunk. I think we should at least get this
>>> done even if the group decides that down the line we want the why
>>> portion explained as well (I actually don't care about the why part).
>>> That feature would require that php_url_parse_ex() add some parsing
>>> intellignce, this would not be a 1 or 2 line feature implementation.
>>>
>>> The motivation is that since false and E_WARN are redunant, this patch
>>> would allow developers to STOP using @parse_url(), which we have to do.
>>>
>>> I also suggest that we apply this to the PHP_5_3 branch. This behavior
>>> should be backwards compatible with everyone that is actually using the
>>> @parse_url() in their code. The only 1-off situation that might be
>>> affected is if people are catching the error with an error handler and
>>> branching there. Why they wouldn't be branching off the false return
>>> value, I don't know.
>>>
>>> Both patches contain test fixes.
>>>
>>> Is there anything more I need? Is this commit worthy?
>>>
>>> Thanks,
>>> Ralph
>>>
>>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>