Re: Re: RC1, instanceof?

Andi Gutmans wrote:

My the way, the performance argument wouldn't work because even if this would be supported, we'd have to first "try" and load the class to make sure we can actually check the instanceof, and only if the class doesn't load then we would return false. So you won't save that step of trying to load the interface/class.

I have wrestled with this 'problem' concerning instanceof since 5.0RC3 (actually Ard B. wrestled on the same code for a while - that is to say Ard B is to my mind a talented ITer and his code is not be written of out of hand - as mine might be if it was just my own, back to the point) regardless of whether it is correct according to anyone else if I do: if ($foo instanceof Bar) { /* yadayada */ } and Bar is a non-existent class then why would one even bother to try a load Bar - $foo is not going to be a Bar - otherwise Bar would exist! In the framework I built with Ard there are dataobjects that contain fields objects - there are quite alot of fields classes and not every 'dataobject' contains everykind of field - in order to a have a generic field handlers (for display/POST-processing etc) that can make use of instanceof I have to load _every_ field class I possibly have - I find it a little sad to hear that obviously the very concept of 'our' framework (let alone the implementation). I also know for a fact I don't fall into 1% of 'black magic'-edge-case-brilliant but-evil-framework-php-programmers, I'm just not that good. I realise I'm not a php developer and my 2cents are worth jack. hopefully this plea from a just-above-average-joe-phper will enlighten you to the fact that there are possibly more people than you realise who feel strongly that instanceof's current implementation should be changed (in accordance with Pierre's arguments) kinds regards (and thanks for your time, and php ofcourse!), Jochem

At 11:56 AM 8/9/2005 +0200, Pierre-Alain Joye wrote:

On Tue, 9 Aug 2005 10:15:15 +0200 (CEST) derick@php.net (Derick Rethans) wrote:

On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:

This technique is already frequently used to cope with lazy loaded code, which even with cached code compilers, is pretty damn efficient in a scripted language (less IO operations, less parsing, less memory...) It is not about the fact we 'can' load the class, but that we dont 'want' to load the class.. - it's a waste of resources, memory, cpu etc. just for the sake of CS perfection.. Last time I looked PHP was about getting thing done efficiently, not about giving your university professor a woody... ;)

That's my point. The autoload magic (crap? :)) is not in cause here. If you _test_ something, you do not expect the test operator to abort your execution (fatal error).

But you're testing for something that you *know* that can not exist in your code base. That is a broken test, so it should throw a fatal error.

function wrapperFoo($obj) {

        if (is_a($obj, 'MyFoo') {
        }
        ... other tests  ....

} worked before is_a was deprecated. function wrapperFoo($obj) {

        if ($obj instanceof MyFoo) {
        }

} Fatal error, if I _known_ that a class _cannot_ exist, I will not test it then, but the thing is that I do _not_ know. If I provide a library (ie, encoded), this library being used in an unknown environment by unknown poeple, or if I have performance requirement and I do not want to require/include a class if I do not have to use it, then this test makes full sense. I fail to see how hard is it to understand... Derick, your post about type hinting talks about the exact same problem, being able to work out fatal error or user mistakes. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php