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.
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
