Re: [PHP-DEV] PHP 5.3.8 Released!

[a...@akbkhome.com]

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, 2011 12:08 AM, Johannes Schlüter wrote:

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
   behavior, which caused mysqlnd SSL connections to hang (Bug
   #55283).

All PHP users should note that the PHP 5.2 series is NOT supported
anymore. All users are strongly encouraged to upgrade to PHP 5.3.8.

For source downloads please visit our downloads page at
, Windows binaries can be found on
.

Johannes Schlüter
PHP 5.3 Release Master






--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.8 Released!

[a...@akbkhome.com]

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 instance of that...


I did read through the previous posts, (just caught up the other day), 
it looks like if anybody really need to do what this new feature 
provides, (which is probably very rare), then


$left == $right || is_subclass_of($left,$right)

should work fine without breaking any code.

Regards
Alan

On Wednesday, August 24, 2011 03:44 PM, Ferenc Kovacs wrote:

On Wed, Aug 24, 2011 at 3:57 AM, 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 need help testing / applying etc..


from what I understand, this won't be changed, as the current behavior
is correct, the old was a bug:

as Stas pointed out:
"Not a bug. $var is interpreted as a class name. To know if one class
extends another, the class in question (first one) should be loaded.
There's no need to load the second one since if it's unknown nothing
can be instance of it and existing classes can not extend it."
if you used this previously

from Dmitry:
"Before the patch, is_a() didn't accept string as the first argument
at all, so it always returned "false" and never triggered
__autoload(). The proposed patch didn't revert to original behavior.
It just disables autoloading and may lead to wrong result.

class a {}
class b extends a {}
var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true

I would say that the old behaviour was wrong, especially because
"instanceof" and is_subclass_of() already implemented support for
string arguments."

so your example was bogus, as passing a non-object as a first
parameter wasn't supported (see http://php.net/is_a) so your code
example depends on an undefined behavior and results in a bogus result
(is_a() alwas returned false if you passed a non-object)

so in a way it is really a BC, but I think that this change is really a bugfix.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.8 Released!

[a...@akbkhome.com]

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, then 
support for strings should have been removed, rather than added.


The problem I have is that this 'feature' is not really that usefull, to 
anyone AFAIKS. (why would you realistically want to do that kind of 
check?) and if you really did need to do such a test, there are other 
trivial ways to do it already (which work across versions).


I know it's reusing code at the backend, but it's a trivial change to 
remove the BC break, and it does not break anything else. (nobody would 
have used it that way yet..).


Regards
Alan

On Wednesday, August 24, 2011 06:43 PM, Zeev Suraski 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 argument, means that if we do anything beyond that - 
e.g. support strings as the first argument - this means we break compatibility 
(please correct me if I misunderstood).  IMHO that's not a realistic way to 
look at retaining compatibility, and I'm saying that as someone who's almost 
religious about maintain compatibility.  With that view of the world, almost 
every bug fix and literally every feature we add - breaks compatibility.

- As a bug fix.  Strings were supported even before this change, but they weren't working properly 
or consistently with the way classes work everywhere else in PHP.  That was fixed.  Just so that we 
feel good about ourselves, we also changed undocumented behavior.  In case it's not clear, a 
situation where is_a("bar", "foo") returns FALSE, even though bar extends foo, 
but bar simply doesn't happen to be loaded in memory at the time of the call - can lead to very 
real world bugs.

Zeev


-Original Message-
From: 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 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 instance of
that...

I did read through the previous posts, (just caught up the other day), it looks
like if anybody really need to do what this new feature provides, (which is
probably very rare), then

$left == $right || is_subclass_of($left,$right)

should work fine without breaking any code.

Regards
Alan

On Wednesday, August 24, 2011 03:44 PM, Ferenc Kovacs wrote:

On Wed, Aug 24, 2011 at 3:57 AM,

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 need help testing / applying etc..


from what I understand, this won't be changed, as the current behavior
is correct, the old was a bug:

as Stas pointed out:
"Not a bug. $var is interpreted as a class name. To know if one class
extends another, the class in question (first one) should be loaded.
There's no need to load the second one since if it's unknown nothing
can be instance of it and existing classes can not extend it."
if you used this previously

from Dmitry:
"Before the patch, is_a() didn't accept string as the first argument
at all, so it always returned "false" and never triggered
__autoload(). The proposed patch didn't revert to original behavior.
It just disables autoloading and may lead to wrong result.

class a {}
class b extends a {}
var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true

I would say that the old behaviour was wrong, especially because
"instanceof" and is_subclass_of() already implemented support for
string arguments."

so your example was bogus, as passing a non-object as a first
parameter wasn't supported (see http://php.net/is_a) so your code
example depends on an undefined behavior and results in a bogus result
(is_a() alwas returned false if you passed a non-object)

so in a way it is really a BC, but I think that this change is really a bugfix.



--
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

Re: [PHP-DEV] PHP 5.3.8 Released!

[a...@akbkhome.com]

" 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 PEAR::isError shows 16,600 matches..

http://www.google.com/codesearch#search/&q=PEAR::isError%20lang:php&type=cs 



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 
will 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 leaving it aside).  The 3 bugs I mentioned (2 from 5.3.7 and one imaginary) have nothing to do with security, and yet we fixed them (or would have fixed them), despite 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 code.  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.


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

Re: [PHP-DEV] PHP 5.3.8 Released!

[a...@akbkhome.com]

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" of is_subclass_of  was originally to return false 
on non-object - andrei (1999)
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=17245&r2=17272 



c) is_a() was introduced by sebastian (2002) and kept this intended 
behaviour
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=67102&r2=69234 



d) when andrey (2004) proposed the change to accepts strings on  
is_subclass_of, he deliberately maintained the existing behaviour for 
is_a()
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=170604&r2=171349 



e) is_a() has a valid use case , and is currently reasonably commonly used.

d) the new behaviour is an uncommon use case, and can be done very 
easily in other ways.



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..


Regards
Alan




On Thursday, August 25, 2011 09:10 AM, Stas Malyshev wrote:

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 wrong 
way they are bugs.



It's use case is reasonably common when doing tests on mixed returns
(method returns PEAR:error, object or normal value.)


That's when you use instanceof.


So we had a situation where a reasonable number of people (eg. anyone
who had used PEAR), had seen and expected the previous behavior.


Seeing wrong code somewhere doesn't mean it's not wrong. There's a 
reason we have the manual.



Please do not fix something that is not broken, and breaks real working
code, just for the hell of it, even in 5.4.


is_a() was broken - it was returning different results from 
essentially the same function is_subclass_of() for no reason at all 
(no, somebody writing buggy code in PEAR using undocumented parameter 
types is not a reason). The reason why we kept is_a() and not killed 
it in favor of instanceof was to have it work with string arguments, 
since instanceof does not. Thus, string arguments should be handled 
properly. I can see how it can be argued that 5.3 is mature enough so 
such changes shouldn't be there, however correct in theory. For 5.4, I 
see no base for argument here.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.8 Released!

[a...@akbkhome.com]

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.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 this not what you are looking for?)

-Ronabop




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php