Hello,
As there is no way to find a solution to the two different vision
(pedantic, non pedantic ;). I propose to do not deprecate is_a.
It cannot hurt neither is_a (is_a uses instanceof too) or
instanceof. The only cons for is_a is a little slow down, which is
negligeable.
Any objection?
Regards,
--Pierre
I don't mind undeprecating it while I continue to digest the whole
instanceof thread and look at real-world examples...
At 09:46 AM 8/10/2005 +0200, Pierre-Alain Joye wrote:
Hello,
As there is no way to find a solution to the two different vision
(pedantic, non pedantic ;). I propose to do not deprecate is_a.It cannot hurt neither is_a (is_a uses instanceof too) or
instanceof. The only cons for is_a is a little slow down, which is
negligeable.Any objection?
Regards,
--Pierre
Hi Andi Gutmans, you wrote:
I don't mind undeprecating it while I continue to digest the whole
instanceof thread and look at real-world examples...
After all I think there's more hidden behind than just
your argument about the generic way...? Why are you
defending this broken bridge that hard?
You're saying that PHP shouldn't be that dynamic regarding
this issue, so why does it try do dynamically load a class
within instanceof (which is needless in every case anyway)?
I think PEAR qualifies as a "real-world" example and there
is_a() is used about 680 times, now if that would be
instanceof and we assume 10% to check for a non-existing
class, it'd bail out at about 70 instances.
Regards,
Michael - < mike(@)php.net