Calling functions whose signature/arguments are only known at runtime

Peter Lobsinger plobsing at gmail.com
Wed Mar 17 13:49:39 UTC 2010


On Wed, Mar 17, 2010 at 8:31 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> Alternate method is to construct your own CallContext PMC. A
> CallContext is created by the invocation anyway, so if you create it
> manually and populate it with the values you need, it doesn't create
> any extra PMCs.
>
> Creating a CallContext is not difficult, and invoking a method with it
> is very simple. Parrot_pcc_invoke_from_sig_object does the trick
> magically. After the call, you can get access to the same CallContext
> object and use it to extract a variable number of returns as well.

Are you saying that this is both a supported and recommended way of
calling into Parrot? For a subsystem that seems to get refactored
frequently, I *really* don't want to break encapsulation.

The lack of docs makes me wary. For example, looking at the output of
"perldoc callcontext.pmc" is not very helpful, you have to RTFS to
figure out that you can use push_{string,integer,float,pmc} to build
up a CallContext PMC. Also, I'd like this technique to show up in some
tests, examples, and/or extending/embedding doc. (Yes, I know I've
just volunteered, it's been added to the queue)

If this method covers everything, why do we expose functions to do the
same thing? Is this just vestigial code? I especially dislike the
functions with misleading names like "sig_object" when we really have
a CallContext.


More information about the parrot-dev mailing list