Re: Re: RC1, instanceof?

From: Date: Tue, 09 Aug 2005 05:44:59 +0000
Subject: Re: Re: RC1, instanceof?
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-17651@lists.php.net to get a copy of this message
On Mon, 08 Aug 2005 14:43:25 -0700 andi@zend.com (Andi Gutmans) wrote: > I don't agree that instanceof on a class which doesn't exist > should work. It doesn't do so in other languages (or at least not > in Java/C++(dynamic_cast)) nor does it really seem to make a lot > of sense and be useful. Sounds more like an edge case you have > hit with some weird code which can probably be written > differently. You cannot compare PHP with Java and C++ in this case, sorry. They work differently for known reason (compiled being one). If you have a method, which could be a factory, or the behaviors depends on which object it gets, you have now 2 choices: - Accept to live with a possible fatal error - Include all single classes you are going to check, even if you will use none of them. The 3rd possibility, fix instanceof. > Today, fetching of classes in the language is very generic, and > they have to exist. I see very few cases where this would not be > true if you are writing a regular application. In those few cases > where you are doing something extremely weird, you can use > reflection to introspect an object. Agreed, that's fetch_class is not opportun for instanceof. My point is not about the fetch_class is done but the way instanceof works. Reflection is terribly overkilled for such a need, and slow. > There is no way this would be changed for RC1 (or PHP 5.1) > because it's a significant change which would affect many places > and not only instanceof. I personally think it shouldn't be > changed at all. If you're referencing classes/exceptions in your > code that don't exist, then something is very bogus with your > code. Don't use a NonExistantException if that could happen, use > Exception... Agreed here too, not related to instanceof though. --Pierre

« previous php.internals (#17651) next »