Everything

php

Home » Project » Newsgroups » php.internals » RC1 »

RC1

php.internals

Andi Gutmans

21 years ago

Hi all,

Another reminder, I'd like to roll RC1 on Monday. Everyone will be back
from OSCON and we can start the Unicode merge right afterwards.

Andi

Pierre-Alain Joye

21 years ago

On Fri, 05 Aug 2005 13:52:13 -0700
andi@zend.com (Andi Gutmans) wrote:

> Hi all,
>
> Another reminder, I'd like to roll RC1 on Monday. Everyone will
> be back from OSCON and we can start the Unicode merge right
> afterwards.

One thing I would like to solve in 5.1 is instanceof (or the
deprecation of is_a).

instanceof is useless much of the times as it raises a fatal error
as soon as the tested class does not exist. Since when tests raise
fatal error?

Sample script:
class test{}
$a = new test;
if ($a instanceof Foo) {
echo "not foo";
}

result:
Fatal error: Class 'Foo' not found in /home/pierre/cvs/builds/
php_head/instanceof.php on line 4


I can write a patch to "fix" it if we agree that the current
behavior is not correct.

Regards,

--Pierre

Pierre-Alain Joye

21 years ago

Hello,

I took a short look to the implementation.

instanceof_ex works as expected, no error display there. The
problem comes from the usage of class_name_reference in the parser.

class_name_reference calls zend_do_fetch_class, which raises this
error as no class is loaded.

Now I'm not sure about a clean solution, it's fine to raise a fatal
error when class_name_reference is used with new, but in the case
of instanceof, it does not make sense.

add a class_name_reference_silent? :)

--Pierre

David Zülke

21 years ago

+1

Michael Wallner

21 years ago

Hi Pierre-Alain Joye, you wrote:

> I can write a patch to "fix" it if we agree that the current
> behavior is not correct.

While you're at it, could you continue on fixing the following:
(another evidence that the current "generic" behaviour is bad)

try {
// anything
} catch (NonExistantException $e) {
}

Fatal error: Class 'NonExistantException' not found


For reference:
http://marc.theaimsgroup.com/?l=php-dev&m=111887012528058&w=2
http://marc.theaimsgroup.com/?l=php-dev&m=109404375329280&w=2
http://marc.theaimsgroup.com/?l=php-dev&m=109218461900310&w=2

Regards,

--
Michael - < mike(@)php.net >

Marcus Börger

21 years ago

Hello Michael,

Monday, August 8, 2005, 6:26:30 PM, you wrote:

> Hi Pierre-Alain Joye, you wrote:

>> I can write a patch to "fix" it if we agree that the current
>> behavior is not correct.

> While you're at it, could you continue on fixing the following:
> (another evidence that the current "generic" behaviour is bad)

> try {
>         // anything
> } catch (NonExistantException $e) {
> }

> Fatal error: Class 'NonExistantException' not found

This is a very different topic. While "instanceof missingclass" can never
result to any problem the former violates hard coded requirements. Thus i
think dropping the message from instanceof is acceptable - but i am not
going to decide this so don't take my second thoughts on this one too
serious.

Best regards,
Marcus

Pierre-Alain Joye

21 years ago

On Mon, 08 Aug 2005 18:26:30 +0200
mike@php.net (Michael Wallner) wrote:

> Hi Pierre-Alain Joye, you wrote:
>
> > I can write a patch to "fix" it if we agree that the current
> > behavior is not correct.
>
> While you're at it, could you continue on fixing the following:
> (another evidence that the current "generic" behaviour is bad)
>
> try {
> 	// anything
> } catch (NonExistantException $e) {
> }
>
> Fatal error: Class 'NonExistantException' not found

You try to declare (if it get catched) a non existent class. Not
really related to instanceof, it's like a new nonexistantclass;

--Pierre

Andi Gutmans

21 years ago

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.

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.

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

Andi


At 08:17 PM 8/8/2005 +0200, Marcus Boerger wrote:

Lukas Smith

21 years ago

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.

Those languages are alot less dynamic at runtime compared to PHP. So I
dont think this is a valid argument.

A common scenario (which I personally dont like) but what is done:
- PEAR.php is loaded on error to generate an instance of PEAR_Error
- inside the code you check for an instance of PEAR_Error being returned
- obviously when no error ever occured you never loaded PEAR.php and kaboom

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

Well the easy solution is to simply undeprecate is_a().

regards,
Lukas

Andi Gutmans

21 years ago

At 11:55 PM 8/8/2005 +0200, Lukas Smith wrote:

>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.
>
>Those languages are alot less dynamic at runtime compared to PHP. So I
>dont think this is a valid argument.
>
>A common scenario (which I personally dont like) but what is done:
>- PEAR.php is loaded on error to generate an instance of PEAR_Error
>- inside the code you check for an instance of PEAR_Error being returned
>- obviously when no error ever occured you never loaded PEAR.php and kaboom

You are right, I don't like it either, and it doesn't explain why it's needed.
A dynamic language and dynamically typed language doesn't mean that
everything should be dynamic if it doesn't make sense. Only what is
necessary should be dynamic and in this case, I have yet to see a
convincing argument of why cleaner static structure is worth changing to
something dynamic. There are other instances, especially in PHP 5's new OO
implementation, where we took a more static approach as it makes more sense
and can be better optimized.

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

>
>Well the easy solution is to simply undeprecate is_a().

I don't mind, but I'm planning on rolling RC1 soon so not sure it'll make
it in. If people agree to un deprecate it I don't mind doing it post RC1 as
chance of something breaking is slim. I still think it's for the wrong
reasons though... You deserve an E_STRICT ;) (just kidding)

Andi

Pierre-Alain Joye

21 years ago

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

Andi Gutmans

21 years ago

You are wrong because __autoload() *is* called and you can load the class
on the-fly. The only problem is if the class does not exist in your code
base, in which case, your application should blow up!

Andi

At 07:44 AM 8/9/2005 +0200, Pierre-Alain Joye wrote:

Alan Knowles

21 years ago

On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote:

> You are wrong because __autoload() *is* called and you can load the class
> on the-fly. The only problem is if the class does not exist in your code
> base, in which case, your application should blow up!

The basic point is that is_a() provided negative testing of non-existant
classes
if (!is_a($obj, "SomeRarelyUsedClass")) { ....

instance_of does not, and can not, at present.

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

Regards
Alan

Pierre-Alain Joye

21 years ago

On Tue, 09 Aug 2005 14:31:08 +0800
alan@akbkhome.com (Alan Knowles) wrote:

> On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote:
> > You are wrong because __autoload() *is* called and you can load
> > the class on the-fly. The only problem is if the class does not
> > exist in your code base, in which case, your application should
> > blow up!
>
> The basic point is that is_a() provided negative testing of
> non-existant classes
> if (!is_a($obj, "SomeRarelyUsedClass")) { ....
>
> instance_of does not, and can not, at present.
>
> 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).

Guys, you are just making PHP more compiled-like. It's a bad idea,
in my opinion.

--Pierre

Derick Rethans

21 years ago

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.

Derick

Pierre-Alain Joye

21 years ago

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

George Schlossnagle

21 years ago

On Aug 9, 2005, at 5:56 AM, 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) {
>     }
> }

To duplicate the old semantic now you need to do:

if(class_exists('MyFoo') && $obj instanceof MyFoo) { }

which is definitely uglier than

if(is_a($obj, 'MyFoo')) {}

George

Andi Gutmans

21 years ago

At 02:07 PM 8/9/2005 -0400, George Schlossnagle wrote:

>To duplicate the old semantic now you need to do:
>
>if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
>
>which is definitely uglier than
>
>if(is_a($obj, 'MyFoo')) {}
>
>George

But that's a good point. For the few frameworks that might require such
functionality they can use class_exists() or other methods. That doesn't
mean we should change instanceof for mainstream usage which is 99.99%.
In all languages, frameworks do some trickier stuff. In Java they often
mess with the ClassLoader, in C++ they deal with DSOs. This kind of
development paradigm is not mainstream and as long as there's a way to
achieve it, then that's what's important.
Even the people that mentioned it's soooo important. I bet that if I look
at their code, there's maybe 1 instance that actually would need this (if
at all).

Andi

Andi Gutmans

21 years ago

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:

Pierre-Alain Joye

21 years ago

On Tue, 09 Aug 2005 12:29:45 -0700
Andi Gutmans <andi@zend.com> wrote:

> we'd have to first "try" and load the class to make
> sure we can actually check the instanceof

Pardon me? :)

As I said in my 2nd post about this topic, the problem (and only
problem here) is that in the lexer, the right part of instanceof is
class_reference_name (from memory for the exact name :), which
corresponds to the normal class fetch, as in "new MyClass".

This is the wrong part of instanceof. Its implementation does not
try to load a class or to raise any single notice/error/warning.


--Pierre

Jochem Maas

21 years ago

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

Lukas Smith

21 years ago

Alan Knowles wrote:

> On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote:
>
>>You are wrong because __autoload() *is* called and you can load the class
>>on the-fly. The only problem is if the class does not exist in your code
>>base, in which case, your application should blow up!
>
>
> The basic point is that is_a() provided negative testing of non-existant
> classes
> if (!is_a($obj, "SomeRarelyUsedClass")) { ....
>
> instance_of does not, and can not, at present.
>
> 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... ;)

I agree with Alan. I guess lazy loading is the key here and __autoload()
to me is about being able to do just that. However if we trigger the
lazy loading mechanism all over the place, then that defeats the
purpose. However like I said the straighforward solution is to
underecate is_a() and leave instanceof as is.

regards,
Lukas

Pasha Zubkov

21 years ago

Alan Knowles wrote:

> The basic point is that is_a() provided negative testing of non-existant
> classes
> if (!is_a($obj, "SomeRarelyUsedClass")) { ....
>
> instance_of does not, and can not, at present.

You can use `if (!($obj instanceof SomeRarelyUsedClass))` ;)

Why statement `$obj instanceof NotLoadedClass` can't evaluate as FALSE
if class not loaded (what with serialized objects?) because if class not
loaded, than object can't be instanceof this class, right?

Pierre-Alain Joye

21 years ago

On Tue, 09 Aug 2005 13:24:56 +0300
pasha.zubkov@gmail.com (Pasha Zubkov) wrote:

> Alan Knowles wrote:
> > The basic point is that is_a() provided negative testing of
> > non-existant classes
> > if (!is_a($obj, "SomeRarelyUsedClass")) { ....
> >
> > instance_of does not, and can not, at present.
>
> You can use `if (!($obj instanceof SomeRarelyUsedClass))` ;)
>
> Why statement `$obj instanceof NotLoadedClass` can't evaluate as
> FALSE if class not loaded (what with serialized objects?) because
> if class not loaded, than object can't be instanceof this class,
> right?

We do __not__ know that.

This test tries to figure that out, exactly that. So no, it must
not end to a fatal error.

--Pierre

Daniel Convissor

21 years ago

On Tue, Aug 09, 2005 at 02:31:08PM +0800, Alan Knowles wrote:

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

Hear, hear!

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

Michael Wallner

21 years ago

Hi Andi Gutmans, you wrote:

> You are wrong because __autoload() *is* called and you can load the
> class on the-fly. The only problem is if the class does not exist in
> your code base, in which case, your application should blow up!

No insult intended, but this is just stubborn. You want to hear a good
reason/argument, so the reason is that there is no reason

- now please read slowly and thouroughly -

to *load* a class for checking an object to be of a specific class

- just because of the simple reason that the checked object can not
be of *that* class, because it doesn't exist.

So what if the mentioned generic way is too "generic"?
There could be a flag to let instanceof *not* die -
a little less generic but more suited for the actual needs IMO.
It may be too late for 5.1 but it's *never* "too late" for
future considerations.

Regards,

--
Michael - < mike(@)php.net >

Stanislav Malyshev

21 years ago

MW>>to *load* a class for checking an object to be of a specific class
MW>>
MW>>- just because of the simple reason that the checked object can not
MW>>  be of *that* class, because it doesn't exist.

I think, if we leave alone the implementation, there's nothing logically
wrong to return false if we ask "is $foo instance of class Bar" and we
don't know what Bar is - just because if we don't know Bar $foo is
definitely not instance of it. Now the only problem I see here is if you
type Bar when you intended to type Baz - but I'm not sure this warrants
the fatal error. Also, autoloading a class is rather expensive operation
in PHP (and loading it regualr way too, generally, if we consider all the
library classes we might need), so IMHO the idea that instanceof may
return (maybe with some warning/notice) false on unknown class doesn't
look that bad to me. Though, then it would be inconsistent with
typehinting, for example - which I feel _should_ error out if typehint
requires unknown class.

MW>>There could be a flag to let instanceof *not* die -
MW>>a little less generic but more suited for the actual needs IMO.

I don't like the idea of all kinds of flags changing language behaviour.
This promotes incompatible coding and effectively forks language into a
set of incompatible sub-languages. Not having any defined behaviour is
much worse than having behaviour that somebody dislikes.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Michael Wallner

21 years ago

Hi Stanislav Malyshev, you wrote:

> Now the only problem I see here is if you
> type Bar when you intended to type Baz - but I'm not sure this warrants
> the fatal error.

Yes, unit tests could catch such issues.

> MW>>There could be a flag to let instanceof *not* die -
> MW>>a little less generic but more suited for the actual needs IMO.
>
> I don't like the idea of all kinds of flags changing language behaviour.
> This promotes incompatible coding and effectively forks language into a
> set of incompatible sub-languages. Not having any defined behaviour is
> much worse than having behaviour that somebody dislikes.

Uh no! I didn't mean an INI or runtime flag, i was talking
about fetch_class - i.e. the internal implementation may flag
if the operation should result in a fatal error.

Regards,

--
Michael - < mike(@)php.net >

Derick Rethans

21 years ago

On Mon, 8 Aug 2005, Andi Gutmans wrote:

> You are wrong because __autoload() *is* called and you can load the class on
> the-fly. The only problem is if the class does not exist in your code base, in
> which case, your application should blow up!

Right, and there is no reason why it shouldn't blow up. The core is
broken, somebody made a typo. Fix it and go on.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Wez Furlong

21 years ago

Maybe a little late throwing my 2 cents in, but here they are anyway.
If you're writing an app that can optionally use a component that is
not present, there is nothing conceptually wrong with calling
instanceof to determine if that support is present; PHP should not
blow up.  If the class is not loaded, then the object can't possibly
be an instance of it, therefore the operator should return false.

--Wez.

On 8/9/05, Andi Gutmans <andi@zend.com> wrote:

Andi Gutmans

21 years ago

I am not stubborn. I just think this has close to 0 use in real-life (or
you're doing some weird coding). In any case, for the one in a million
case, I think Reflection is good enough.

Andi

At 08:40 AM 8/9/2005 +0200, Michael Wallner wrote:

Lukas Smith

21 years ago

Andi Gutmans wrote:

> I am not stubborn. I just think this has close to 0 use in real-life (or
> you're doing some weird coding). In any case, for the one in a million
> case, I think Reflection is good enough.

I worded my example a bit wrong. I dont like people loading PEAR.php on
demand. However I think the need is quite real. In PHP its quite natural
to load code on demand and in sufficiently modular code its quite
realistic that one piece of code will not know about what code was
loaded and therefore use something like instanceof to determine what
instance its dealing with.

Anyways I think sufficient numbers of people have experessed that they
would like this functionality which was provided by the deprecated
is_a() method. So the decision to make seems to be if:

1) is_a() should simply be undeprecated

2) instanceOf be modified

I am +1 on 1)

regards,
Lukas