At 4:08 PM +0000 1/11/03, Nicholas Clark wrote:
Sorry. The assumption is one of three things happen:On Thu, Jan 09, 2003 at 04:40:20PM -0500, Dan Sugalski wrote:The find_method vtable entry should die, and be replaced with a plain method entry. This should return either the address of the start of the method's bytecode, or NULL. The NULL return is for those cases where the method actually executed via native code, and thus doesn't have to go anywhere. If an address is returned it's expected that the engine will immediately dispatch to that spot, obeying parrot's calling conventions.What about the case where the object doesn't have the method you're asking for? You seem to be using NULL to mean something other than "not found", so does that mean not found is an exception?
1) A value is returned, which is the address of the parrot code to dispatch to
2) A NULL is returned, which indicates the method call has been made and the interpreter can proceed to the next instruction in the stream
3) An exception is thrown, indicating that the method couldn't be called.
And if NULL is returned it is expected that the method has already been called? If so, there doesn't seem to be any way to find out if a PMC possesses (modulo AUTOLOAD) a method, without the danger of it being called.
If we don't have a can in the vtable, then we need to fix that. :)
Parrot will have an AUTOLOAD-style fallback mechanism available to it. I'll add that to the design todo list for the edited version of objects.Will there be anything built in at parrot level like Perl's AUTOLOAD system? Or will that have to be done explicitly by the perl6 code generator wrapping methods in a routine that catches the "not found" exception, and attempts to use AUTOLOAD? [and whatever multimatch despatch system perl6 will be using to find the "best" method]
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk