At 4:08 PM +0000 1/11/03, Nicholas Clark wrote:
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?
Sorry. The assumption is one of three things happen:

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

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

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk

Reply via email to