Calling functions whose signature/arguments are only known at runtime

Peter Lobsinger plobsing at gmail.com
Wed Mar 17 18:21:48 UTC 2010


On Wed, Mar 17, 2010 at 11:26 AM, Allison Randal <allison at parrot.org> wrote:
> A flattened aggregate PMC is the way to go at the moment, until we get
> :sig_object fully added and fully tested (it's still marked as
> "experimental"). If we do callback arguments (and I'm still not entirely
> convinced it's a good idea), I'd rather see it integrated with
> Parrot_ext_call() than added as a separate function. As in, you have a
> signature sub-type 'b' ('c' is already taken for constants), and specify
> "IbSbNbPb" and pass in 4 function pointers for how to load the 4 different
> types.
>
> This gives more flexibility to pass in some direct arguments first in the
> signature, and then use the callbacks for any remaining arguments required
> (say, "PiPb" for passing in a method object direct and the rest of the PMC
> arguments using callbacks). It would also allow you to only specify
> callbacks for specific types (PMCs and strings, for example).
>
> It's also a cleaner interface for maintenance, because it doesn't expose the
> structs of function pointers we currently use internally for arg
> fetching/setting (but may not always use).

Any stable, supported solution that can get the full functionality out
of PCC would be great. If we explicitly support embedders creating
their own CallContexts, that sounds like it fits the bill.

While I do like callbacks, I'm not sure integrating them into PCC
signatures is a great idea. PIR->PIR calls (>90% of all PCC use?)
likely wouldn't have any use for this functionality. And if
CallContext already does the job, they probably aren't needed. The
small win I did see isn't worth that much polution.


More information about the parrot-dev mailing list