What are you talking about? The change is exactly about that, change the behavior when a string is passed.
We are back to the discussion about undeprecating is_a, from scratch...
It hurts codes and apps with 5.3, let do it in 5.4 only.
----- Reply message -----
From: "Stas Malyshev" smalyshev@sugarcrm.com
Date: Wed, Aug 24, 2011 19:00
Subject: [PHP-DEV] PHP 5.3.8 Released!
To: "alan@akbkhome.com" alan@akbkhome.com
Cc: "internals@lists.php.net" internals@lists.php.net
Hi!
" 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....
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
objects. The fact that this bug remained for 8 years is very sad, but it
doesn't cease to be a bug.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
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. If your
code relies on that, it has a bug, fix it.
We are back to the discussion about undeprecating is_a, from scratch...
No we're not. It is not deprecated, nobody proposes to deprecate it -
how we're back?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
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. If your code
relies on that, it has a bug, fix it.
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).
Now call that a bug, fine, but it is a breakage in a patch release.
We are back to the discussion about undeprecating is_a, from scratch...
No we're not. It is not deprecated, nobody proposes to deprecate it - how
we're back?
About why it should not suddenly changes this working perfectly fine
before. And about not calling autoload.
Arguments have been given, by many and in all possible ways. I do not
see a consensus coming out (while Zeev just realized what we are
talking about when we say 'breakage'). I propose to go for a vote to
see what we should do with this fix in the 5.3 branch.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
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 "perfectly fine". Like
calling file_exists on an array argument and relying on the fact that
file by the name "Array" does not exist (it doesn't work this way, but
could have worked in some old version). This is not a correct usage, it
is just by chance does what you intended. Passing invalid arguments to a
function and relying it would work properly is not a good idea.
Now call that a bug, fine, but it is a breakage in a patch release.
In general, I do not think we can promise bug compatibility, and
shouldn't encourage people to expect it. In this particular instance, we
may or may not make an exception, depending on how important is to have
is_a work with strings. If we leave strings functionality in,
autoloading should be a part of it, it's the only way it makes sense.
But we could as well not include string support for is_a() in 5.3, it's
not a critical fix IMHO.
About why it should not suddenly changes this working perfectly fine
before. And about not calling autoload.
It did not work "perfectly fine" before. This code relied on a buggy
undocumented behavior, in no universe it is "perfectly fine".
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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 arguing.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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 arguing.
So 5.3.8 is dead as well? Since we now need 5.3.9 to roll this back?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php