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)
[EMAIL PROTECTED] (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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
