On Wed Aug 24 08:42 AM, Pierre Joye wrote:
Hi Alan,
the breakage is about is_a with a string as 1st argument, not is_a as
a whole. So yes, it breaks is_a alone is used as validation.
I've been digging more into this:
Hi,
On Fri, Sep 2, 2011 at 13:26, Jonathan Bond-Caron jbo...@openmv.com wrote:
On Wed Aug 24 08:42 AM, Pierre Joye wrote:
Hi Alan,
the breakage is about is_a with a string as 1st argument, not is_a as
a whole. So yes, it breaks is_a alone is used as validation.
I've been digging
We already discussed that *in length* the past couple of weeks, the patch
was in fact intentional and we decided not to revert it.
I'm ok with the decision,
but what about adding a third argument [, bool $autoload = true ] to is_a()
and is_subclass_of(),
in order to be consistent with
On Thu, Aug 25, 2011 at 3:51 AM, a...@akbkhome.com a...@akbkhome.com wrote:
BTW. we could really do with a searchable archive of php.dev + internals...
- It's pretty difficult to find out if this was ever discussed before..
Again, it was discussed already and the argument of using instanceof
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, August 25, 2011 11:31 AM
To: a...@akbkhome.com
Cc: Stas Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
On Thu, Aug 25, 2011 at 3:51 AM, a...@akbkhome.com
On Thu, Aug 25, 2011 at 10:39 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, August 25, 2011 11:31 AM
To: a...@akbkhome.com
Cc: Stas Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.3.8 Released
On Thu, 2011-08-25 at 08:39 +, Zeev Suraski wrote:
- Given that we've already done it - I wouldn't revert it. Fix it in
PEAR. That's the only way to create something that works across all
versions of 5.3.x.
Unfortunately this is the case.
johannes
--
PHP Internals - PHP Runtime
On 2011-08-25, a...@akbkhome.com a...@akbkhome.com wrote:
I'm not sure it's possible to get agreement on if this is a bug or
not, you might see a bug, I just see this as a pointless change for
consistency that pretty much nobody will ever need or use.
Please don't generalize based on your own
On Wed, Aug 24, 2011 at 3:57 AM, a...@akbkhome.com a...@akbkhome.com wrote:
It might have been better to have waited for the is_a() fix to get sorted
out.. - It's a very annoying BC break (changes the documented behaviour),
and now it means we need 4.3.9 in a few more days.
Let me know if you
On 08/24/2011 03:57 AM, a...@akbkhome.com wrote:
It might have been better to have waited for the is_a() fix to get sorted
out.
No, it would have been better if the only difference between PHP 5.3.7
and PHP 5.3.8 would have been the fix for the crypt() issue.
--
Sebastian Bergmann
Am 24.08.2011 10:06, schrieb Sebastian Bergmann:
On 08/24/2011 03:57 AM, a...@akbkhome.com wrote:
It might have been better to have waited for the is_a() fix to get sorted
out.
No, it would have been better if the only difference between PHP 5.3.7
and PHP 5.3.8 would have been the fix
On Wed, 24 Aug 2011, Ferenc Kovacs wrote:
On Wed, Aug 24, 2011 at 3:57 AM, a...@akbkhome.com a...@akbkhome.com wrote:
It might have been better to have waited for the is_a() fix to get sorted
out.. - It's a very annoying BC break (changes the documented behaviour),
and now it means we need
Since when has changing documented behaviour and breaking a large number
of applications been acceptable? (Well, happens occasionally by accident ..)
This was a 'feature change' to is_a(), it was documented as _only_
returning 'TRUE' when an object was passed as the first object and it
was an
On Wed, Aug 24, 2011 at 11:36 AM, Derick Rethans der...@php.net wrote:
On Wed, 24 Aug 2011, Ferenc Kovacs wrote:
On Wed, Aug 24, 2011 at 3:57 AM, a...@akbkhome.com a...@akbkhome.com wrote:
It might have been better to have waited for the is_a() fix to get sorted
out.. - It's a very annoying
agreed.
On Wed, Aug 24, 2011 at 11:36 AM, Derick Rethans der...@php.net wrote:
On Wed, 24 Aug 2011, Ferenc Kovacs wrote:
On Wed, Aug 24, 2011 at 3:57 AM, a...@akbkhome.com a...@akbkhome.com wrote:
It might have been better to have waited for the is_a() fix to get sorted
out.. - It's a
On Wed, Aug 24, 2011 at 12:00 PM, Pierre Joye pierre@gmail.com wrote:
agreed.
about this specific change:
the real problem is that nobody spotted this change until we rolled
out the stable release, after that we can only chose from bad options.
we could have spotted this via two ways:
-
the problem is to change existing tests to match a possible fix,
that defeats the whole purpose of testing possible BC breaks using our
test suites.
We should definitively run x.y.0 tests during the whole x.y.0 life,
and if something has to be changed, then it should be 1st be
discussed, or RFC
On Wed, 2011-08-24 at 12:24 +0200, Ferenc Kovacs wrote:
we could have spotted this via two ways:
- those who participated in fixing
https://bugs.php.net/bug.php?id=53727 could have spotted this
- our tests should have start failing after the change
Third option:
- RC testers might have
: a...@akbkhome.com [mailto:a...@akbkhome.com]
Sent: Wednesday, August 24, 2011 12:37 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
Since when has changing documented behaviour and breaking a large
number of applications been acceptable? (Well, happens occasionally
Quoting Johannes Schlüter johan...@schlueters.de:
I have the impression that very few people actually test these. When
creating an RC we inform the primary testers as well as qa and
internals list members. From there I get one or two responses in
general.
What happens to the reports that make
2011/8/24 Johannes Schlüter johan...@schlueters.de:
On Wed, 2011-08-24 at 12:24 +0200, Ferenc Kovacs wrote:
we could have spotted this via two ways:
- those who participated in fixing
https://bugs.php.net/bug.php?id=53727 could have spotted this
- our tests should have start failing after the
On Wed, Aug 24, 2011 at 1:04 PM, Dirk Haun d...@haun-online.de wrote:
Quoting Johannes Schlüter johan...@schlueters.de:
I have the impression that very few people actually test these. When
creating an RC we inform the primary testers as well as qa and
internals list members. From there I get
On Wed, Aug 24, 2011 at 12:43 PM, Zeev Suraski z...@zend.com wrote:
I think there are two ways to look at it:
- As a new feature. If I understand you correctly, the fact that beforehand
is_a() was documented to only return TRUE in case the first argument was an
instance of the second
2011/8/24 Ferenc Kovacs tyr...@gmail.com:
2011/8/24 Johannes Schlüter johan...@schlueters.de:
On Wed, 2011-08-24 at 12:24 +0200, Ferenc Kovacs wrote:
we could have spotted this via two ways:
- those who participated in fixing
https://bugs.php.net/bug.php?id=53727 could have spotted this
-
@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
Since when has changing documented behaviour and breaking a large
number of applications been acceptable? (Well, happens occasionally by
accident ..)
This was a 'feature change' to is_a(), it was documented as _only_ returning
'TRUE' when
Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
It's not really a bug fix, as the document for is_a() never said it would
support
'mixed' first argument. (is_subclass_of is different, it currently says mixed
as
the first argument). If it needed fixing
No matter what it is or how it is defined by us, it breaks existing code and
that
should be avoided in bug fixes releases like 5.3.7/8.
Pierre,
This wholesale statement doesn't get us anywhere. Every bug fix can result in
breaking existing code. If due to a logic error, under some
On Wed, Aug 24, 2011 at 1:40 PM, Zeev Suraski z...@zend.com wrote:
No matter what it is or how it is defined by us, it breaks existing code and
that
should be avoided in bug fixes releases like 5.3.7/8.
Pierre,
This wholesale statement doesn't get us anywhere.
It does, we underestimate
Ferenc Kovacs wrote:
the aggregated report summaries are available at
http://qa.php.net/reports/ thanks to Oliver Doucet who make this
happen.
Which, incidentally, doesn't appear to be working at this point in time.
--
Ryan McCue
http://ryanmccue.info/
--
PHP Internals - PHP Runtime
This wholesale statement doesn't get us anywhere.
It does, we underestimate the situation and this fix/improvement/consistency
change breaks apps and codes out there.
And I do not consider it as acceptable at this stage in 5.3.x. Let do it only
in
5.4.
How is it different from any of
On Wed, Aug 24, 2011 at 1:59 PM, Ryan McCue li...@rotorised.com wrote:
Ferenc Kovacs wrote:
the aggregated report summaries are available at
http://qa.php.net/reports/ thanks to Oliver Doucet who make this
happen.
Which, incidentally, doesn't appear to be working at this point in time.
it
On Wed, Aug 24, 2011 at 2:00 PM, Zeev Suraski z...@zend.com wrote:
This wholesale statement doesn't get us anywhere.
It does, we underestimate the situation and this fix/improvement/consistency
change breaks apps and codes out there.
And I do not consider it as acceptable at this stage in
Quoting Ferenc Kovacs tyr...@gmail.com:
On Wed, Aug 24, 2011 at 1:59 PM, Ryan McCue li...@rotorised.com wrote:
Ferenc Kovacs wrote:
the aggregated report summaries are available at
http://qa.php.net/reports/ thanks to Oliver Doucet who make this
happen.
Which, incidentally, doesn't appear
by case basis. It is now very well known that when a fix requires a test
change,
then it often leads to bc breaks or similar issues.
I do not think we have to argue about the semantics or general cases but how
to avoid such things and be sure that we break as less code as possible in
On Wed, Aug 24, 2011 at 2:15 PM, Dirk Haun d...@haun-online.de wrote:
Quoting Ferenc Kovacs tyr...@gmail.com:
On Wed, Aug 24, 2011 at 1:59 PM, Ryan McCue li...@rotorised.com wrote:
Ferenc Kovacs wrote:
the aggregated report summaries are available at
http://qa.php.net/reports/ thanks to
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
that for 8 years
google search for
Hi Alan,
the breakage is about is_a with a string as 1st argument, not is_a as
a whole. So yes, it breaks is_a alone is used as validation.
On Wed, Aug 24, 2011 at 2:38 PM, a...@akbkhome.com a...@akbkhome.com wrote:
If it's a clear bug, which IMHO this is_a() issue was - then unless we're
@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
Message-
From: a...@akbkhome.com [mailto:a...@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
On 8/24/11 3:42 AM, Johannes Schlüter wrote:
We don't push them out as news on the php.net frontpage and we don't
send it out to the announce list for reasons like not confusing users.
Should we change that?
Announcements of RC X, Alpha X etc should be on the frontpage.
Chris
--
Email:
On Wed, 2011-08-24 at 07:47 -0700, Christopher Jones wrote:
On 8/24/11 3:42 AM, Johannes Schlüter wrote:
We don't push them out as news on the php.net frontpage and we don't
send it out to the announce list for reasons like not confusing users.
Should we change that?
Announcements of
Hi!
On 8/24/11 5:38 AM, a...@akbkhome.com wrote:
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
...@sugarcrm.com
Date: Wed, Aug 24, 2011 19:00
Subject: [PHP-DEV] PHP 5.3.8 Released!
To: a...@akbkhome.com a...@akbkhome.com
Cc: internals@lists.php.net internals@lists.php.net
Hi!
On 8/24/11 5:38 AM, a...@akbkhome.com wrote:
If it's a clear bug, which IMHO this is_a() issue was - then unless
Hi!
On 8/24/11 10:56 AM, pierre@gmail.com wrote:
What are you talking about? The change is exactly about that, change the
behavior when a string is passed.
Code relying on passing string to is_a is buggy, since it is clearly
documented as accepting object. That's what I am talking about.
On Wed, Aug 24, 2011 at 8:02 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
On 8/24/11 10:56 AM, pierre@gmail.com wrote:
What are you talking about? The change is exactly about that, change the
behavior when a string is passed.
Code relying on passing string to is_a is buggy,
Hi!
On 8/24/11 11:05 AM, Pierre Joye wrote:
As it was working perfectly fine until now, it was perfectly fine to
use is_a only to valid possible instances of a given class, passing a
non object returned false, which was totally correct (per se).
I think you are confusing worked for me with
Stas Malyshev wrote:
mmh.. how much breakage did you want.
PEAR::isError is basically is_a($input, 'PEAR_Error'); it's been like
that for 8 years
So, PEAR has a bug, if it passes non-object argument to is_a, as previously is_a
was only documented (and actually still is) as accepting
Hi!
On 8/24/11 1:45 PM, Lester Caine wrote:
If I am reading things right, is_a was only designed to handle an object, so
feeding it a mixed parameter in isError was always wrong? As far as I can see,
on the whole, the PEAR code only ever feeds an object and feeding it a string
would have to be
If I am reading things right, is_a was only designed to handle an object, so
feeding it a mixed parameter in isError was always wrong? As far as I can
see, on the whole, the PEAR code only ever feeds an object and feeding it a
string would have to be a real error? So there are a number of
Hi!
Thanks for providing the timeline.
On 8/24/11 2:15 PM, Ferenc Kovacs wrote:
5, Helgi fixed Pear in the meanwhile
http://svn.php.net/viewvc/pear/pear-core/tags/PEAR-1.9.5/PEAR.php?r1=313081r2=313083pathrev=313340
This fix doesn't look good - it doesn't do what is was meant to do.
7,
On Wed, Aug 24, 2011 at 11:33 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Thanks for providing the timeline.
On 8/24/11 2:15 PM, Ferenc Kovacs wrote:
5, Helgi fixed Pear in the meanwhile
On Wed, Aug 24, 2011 at 10:21 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
I think you are confusing worked for me with perfectly fine.
Sorry, but as I agreed to adapt it in trunk/5.4, it cannot be changed
in 5.3, period. The reasons have been explained enough times already,
with examples of
Pierre Joye wrote:
I think you are confusing worked for me with perfectly fine.
Sorry, but as I agreed to adapt it in trunk/5.4, it cannot be changed
in 5.3, period. The reasons have been explained enough times already,
with examples of working codes out there. Now let vote on that instead
of
Some real history for the young ones ;)
If you go all the way back to when is_a() was introduced, it appears
that it was done to simplify the code in PEAR::isError, which basically
did stuff like
if is_object() and is subclass() or get_classname() == ...
So the previous behavior was very
Hi!
On 8/24/11 4:38 PM, Alan Knowles wrote:
Some real history for the young ones ;)
I wonder who you are meaning... :)
So the previous behavior was very likely the 'designed' behavior. Not an
accidental side effect, or bug.
Bugs can be very well intentional, but if they use the language
I'm not sure it's possible to get agreement on if this is a bug or not,
you might see a bug, I just see this as a pointless change for
consistency that pretty much nobody will ever need or use.
I think I'll leave it as
a) no bug was ever reported on the previous behaviour.
b) intended design
On Wed, Aug 24, 2011 at 6:51 PM, a...@akbkhome.com a...@akbkhome.com wrote:
BTW. we could really do with a searchable archive of php.dev + internals...
- It's pretty difficult to find out if this was ever discussed before..
http://marc.info/?l=php-internals
marc has a ton of the PHP lists. (Is
It did not like my search for is_a ;) - I guess it's too short.
On Thursday, August 25, 2011 11:59 AM, Ronald Chmara wrote:
On Wed, Aug 24, 2011 at 6:51 PM, a...@akbkhome.coma...@akbkhome.com wrote:
BTW. we could really do with a searchable archive of php.dev + internals...
- It's pretty
For the record, I'd like to point out I do need the new behaviour.
In 5.3.6 you need reflection to check if a class implements an interface.
You also need to check is_subclass_of AND compare the lowercased classes.
All that is about 5 times slower than is_a in 5.3.8.
Probably it should be
The PHP development team would like to announce the immediate
availability of PHP 5.3.8. This release fixes two issues introduced in
the PHP 5.3.7 release:
* Fixed bug #55439 (crypt() returns only the salt for MD5)
* Reverted a change in timeout handling restoring PHP 5.3.6
It might have been better to have waited for the is_a() fix to get
sorted out.. - It's a very annoying BC break (changes the documented
behaviour), and now it means we need 4.3.9 in a few more days.
Let me know if you need help testing / applying etc..
Regards
Alan
On Wednesday, August 24,
61 matches
Mail list logo
