The following patch makes Parrot_get_name report a different error message if Parrot_MMD_search_default_func finds nothing, to distinguish this from the case where nothing is found. I am finding this helpful in debugging.
But this seems like a band-aid, for two reasons:
1. find_name can never return a MultiSub, and find_global doesn't seem to work. So I can't get a handle on a MultiSub built for me by IMCC.
C<find_name> just searches in more namespaces, namely: lexicals, globals, and "__parrot_core". A C<find_global> in the latter name space should return a builtin MultiSub PMC.
2. Even if I had it, I couldn't call it, because the dispatch is done by find_name.
Well, C<find_name> should probably return the real callable sub, it it's exexcuted inside a call sequences, that is S1 has the signature and call arguments are already in place.
If there is no signature in S1, it should just return the MultiSub - which it seems not do now.
*But* that is all really weak, because S1 could have any value - see e.g. at the end of mmd_arg_tuple_func(): REG_STR(1) is cleared there for this reason.
There is currently no real fix for this, we first have to fix calling conventions.
Seems to me (IMHO) that the MultiSub invoke method is the right place
to do the actual dispatching, but I don't understand all the magic
involved.
The MultiSub PMC is invocable and the dispatch actually happens there for bound multi-methods. But we really should avoid dispatching inside the MultiSub if possbile for performance reasons.
... Also, this would seem to interact with changes to the calling conventions [1], so perhaps this patch is premature.
Yeah, we should first to the calls right.
Is there a MultiSub API, or one in the works?
You can push another candidate on it via VTABLE_push_pmc and you can invoke it, well, it inherits from ResizablePMCArray, so you can do everything what you can do with an array.
-- Bob Rogers http://rgrjr.dyndns.org/
[1] Leo, "[PROPOSAL] call syntax abstraction", Tue, 03 May 2005 13:58:14 +0200.
Yeah.
--- src/global.c (revision 8008) +++ src/global.c (working copy)
Dunno, if we should change that now.
leo
