Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48422
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=PsWdVjHOyy6TReLfaasRWKsMTQyCLYEyvj9s0DnUwjOTaW5fcCHIMxYs+5fhC+5QjK
         DHS79nRZXMV4JaLGKgEMHBtCdF+WexK28ILSHjBNJvWkURYmbrAMbU+yvdyNV+fjkX56
         1Nf1l8dnDDKSSIRodtOwfQRVpifSXy/6CI12A=
MIME-Version: 1.0
Sender: tjerk.meesters@gmail.com
In-Reply-To: <4BFA18D6.5030209@moonspot.net>
References: <4BF6A90D.8020901@smashlabs.com> <4BF6AD07.7090001@moonspot.net>
	 <AANLkTilyZUdos7iUfPaAgvN89g1m4Gf9A1_4gXyBjQPu@mail.gmail.com>
	 <4BFA18D6.5030209@moonspot.net>
Date: Mon, 24 May 2010 15:50:59 +0800
Message-ID: <AANLkTikhYlpYIvs5N4Y3vU6-LtDTz2gz8qI2hceshKZa@mail.gmail.com>
To: Brian Moon <brian@moonspot.net>
Cc: Ilia Alshanetsky <ilia@prohost.org>, Ralph Schindler <ralph@smashlabs.com>, 
	internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Fixes for parse_url, bug 50563
From: datibbaw@php.net (Tjerk Anne Meesters)

On Mon, May 24, 2010 at 2:12 PM, Brian Moon <brian@moonspot.net> wrote:
> Because that is, IMO, a bad precedent to start for PHP internal functions=
.
> Too many functions already produce warnings (fopen) and return a status t=
hat
> 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 distribut=
ed
> software not be able to deal with these functions and return useful messa=
ges
> instead of spewing warnings uncontrollably. I am all for turning off
> warnings when a function returns a success/failure status.

And when this success/failure status is actually being used in the
calling code I assume? ;-)

>
> 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 th=
e
>> 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> =A0wrot=
e:
>>
>>> +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 situatio=
ns
>>>> 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 warnin=
g
>>>> gives no more information than simply returning false does.
>>>>
>>>> http://bugs.php.net/bug.php?id=3D50563
>>>>
>>>> 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 th=
e
>>>> @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
>>>
>>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
--
Tjerk