Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54882
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.42 as permitted sender)
MIME-Version: 1.0
Sender: johnjawed@gmail.com
In-Reply-To: <887FE7CFF6F8DE4BB3A9535F53AFD06A495AB2E5@il-ex2.zend.net>
References: <1314115682.2635.98.camel@guybrush>
	<4E545A6C.60704@akbkhome.com>
	<CAH-PCH5jyEQZvwgqxkUpqN7a-VUc+nYt=_ixFQ1si64xxMBw4A@mail.gmail.com>
	<4E54C658.6070209@akbkhome.com>
	<887FE7CFF6F8DE4BB3A9535F53AFD06A495AAA2F@il-ex2.zend.net>
	<CAEZPtU4TQ_-FnrqosWfLx8xvQvgtPi2BnhkV3o=J43056Lxoeg@mail.gmail.com>
	<887FE7CFF6F8DE4BB3A9535F53AFD06A495AAE17@il-ex2.zend.net>
	<CAEZPtU5Hy6rqbj0DMVg+HhJ2yMoSA2O4ErNpwbe0JuKc0t=jrw@mail.gmail.com>
	<887FE7CFF6F8DE4BB3A9535F53AFD06A495AB00F@il-ex2.zend.net>
	<CAEZPtU7MLoH=vQ2S12keYtPtoQT9fDb9YLQrF4qOSU=iA0M+nw@mail.gmail.com>
	<887FE7CFF6F8DE4BB3A9535F53AFD06A495AB153@il-ex2.zend.net>
	<4E54F0D6.9030005@akbkhome.com>
	<887FE7CFF6F8DE4BB3A9535F53AFD06A495AB2E5@il-ex2.zend.net>
Date: Wed, 24 Aug 2011 07:46:00 -0700
Message-ID: <CAB75mSWRMTWgqfXtWgzmbKwN5nVLD7bZwyb76J6+cuT2c8P0Qg@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: "alan@akbkhome.com" <alan@akbkhome.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
From: jawed@php.net (JJ)

I think it's too late to do much of anything other than document the
change in a way that makes it easier for people to recognize. I spoke
to Philip about this offline and I think the two options along these
lines are:

1) Add a WARNING box which specifies the change for the function, that
a true type check for strings no longer yields FALSE
2) Update the first argument documentation from object -> mixed,
mention it has started accepting mixed as of 5.3.7, and highlight the
fact this function no longer returns FALSE when the type check (for
strings) fails.

fwiw - the pre-5.3.7 behavior was sub-optimal/broken but this is a BC
break, if you consider modifying an existing function signature a BC
break (which I'd hope most people do).

I realize the release RFC isn't live till 5.4 but I am concerned that
the continuing debate around what is and isn't a BC break, which has
taken a large chunk of this thread, will hinder the relrfc moving
forward.

- JJ

On Wed, Aug 24, 2011 at 5:50 AM, Zeev Suraski <zeev@zend.com> wrote:
> Well, I have to admit this is mighty convincing :) =C2=A0Wasn't aware of =
this use-case. =C2=A0Falls under the category of mass breakage I guess.
>
> Zeev
>
>
>> -----Original Message-----
>> From: alan@akbkhome.com [mailto:alan@akbkhome.com]
>> Sent: Wednesday, August 24, 2011 3:39 PM
>> To: Zeev Suraski; internals@lists.php.net
>> Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
>>
>> " If it's a clear bug, which IMHO this is_a() issue was - then unless we=
're
>> looking at code breakage at massive scale, it should be fixed. "
>>
>> mmh.. how much breakage did you want.
>>
>> PEAR::isError is basically is_a($input, 'PEAR_Error'); it's been like th=
at for > 8
>> years....
>>
>> google search for PEAR::isError shows 16,600 matches..
>>
>> http://www.google.com/codesearch#search/&q=3DPEAR::isError%20lang:php&
>> type=3Dcs
>> <http://www.google.com/codesearch#search/&q=3DPEAR::isError%20lang:php
>> &type=3Dcs>
>>
>> for is_a you get 149K. and this is only public code...
>>
>> It's big... Luckily quite a few people are on holiday this month and wil=
l not
>> upgrade too soon.
>>
>> Regards
>> Alan
>>
>>
>>
>> On Wednesday, August 24, 2011 08:22 PM, Zeev Suraski wrote:
>> >
>> > It has nothing to do with security (criticality is subjective so I'm l=
eaving it
>> aside). =C2=A0The 3 bugs I mentioned (2 from 5.3.7 and one imaginary) ha=
ve nothing
>> to do with security, and yet we fixed them (or would have fixed them), d=
espite
>> the potential for people out there relying on the old behavior. It boils=
 down to
>> evaluating the severity of the bug and the likelihood that it'll break c=
ode. =C2=A0If it's
>> a clear bug, which IMHO this is_a() issue was - then unless we're lookin=
g at
>> code breakage at massive scale, it should be fixed.
>> >
>> > Again, I'm almost religious about retaining compatibility (even across=
 major
>> versions), but if we had a piece of code that was returning clearly the =
wrong
>> value, we can't ignore it because some (my guess very few but who knows)
>> relied on this behavior.
>> >
>> > Zeev
>> >
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>