Re^2: Reflecting on Object

Actually, this isn't equivalent to the halting problem. If you can guarentee that there are no other threads executing, it's possible to guarentee that the code you write to discover the available methods doesn't modify $obj in any way, and so you can know what methods are available right now. The problem is that that information is only good until you execute some code that might change $obj. It's also impossible to compensate for AUTOLOAD.

Comment on Re^2: Reflecting on Object

Replies are listed 'Best First'.
Re^3: Reflecting on Object by halley (Prior) on Jul 21, 2005 at 14:29 UTC
You break your own argument here. From the caller's point of view, a call appears atomic, but thanks to AUTOLOAD, the call itself is able to modify the world, even before the eventually-installed method is entered. You can stop time just before the call, and still not prove what methods are available. QED. And words are important: I said 'akin,' not 'equivalent.' There are differences. However, they're both in a group of unprovable-because-the-domain-can-change problems. -- `[ e d @ h a l l e y . c c ]`	[reply]
Re^4: Reflecting on Object by Anonymous Monk on Jul 21, 2005 at 14:53 UTC
What the other AM means is that it is possible to determine which subroutines are available to classes (including the AUTOLOAD routine) without the class getting a chance to modify itself (or some code to modify the class). There's no need to call a method to find out whether it is defined. However, you cannot find out what is dealt with by AUTOLOAD (well, technically, if there's an AUTOLOAD, anything is dealt with, even if dealing with means not doing anything - if there's an AUTOLOAD, you won't get a perl generated "Can't locate object method" error for that class.	[reply]
Re^4: Reflecting on Object by jdporter (Paladin) on Jul 21, 2005 at 14:58 UTC
"the call itself"? What call? I see no call here. We're not calling anything, we're just walking through the symbol table.	[reply]