Jonathan Leto wrote:
Howdy,
On Tue, Mar 16, 2010 at 12:19 PM, Andrew Whitworth
<[email protected]> wrote:
My initial thought, and this isn't implemented quite yet (though we
could put the fire back to my feet to complete it) is to create a
CallContext PMC with all the arguments you want and pass that in.
This sounds interesting, what do we get if we go this route? Does it
make certain things easier/faster/more portable?
The main advantage is that it's a dynamic container to hold arguments
that a) already has to be created for the call, so it's not an extra PMC
to create, and b) does typed storage, so you don't have to create a PMC
to hold each int, num, or str, they're stored directly.
Putting arguments into a ResizablePMCArray or Hash and using :flat
(Signature "Pf") would similarly resolve the problem.
Good idea! I think that we could make stuff work at the PIR level
going that route, but I don't think HLL's would work using that
method. But it gives us a path forward, which is very good. I still
think that Parrot_ext_call_cb is going to be the way to get HLL
argument passing working correctly, perhaps wrapped in some kind of
container PMC.
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).
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
