On Aug 11, 2005, at 3:41 AM, Nathaniel Gray wrote:
On Aug 10, 2005, at 6:56 PM, Sherm Pendley wrote:
I think those details are pretty well hidden by the marg_* macros
though. I've used method_getArgumentInfo() to get the offset of
the argument, and marg_setValue() to set it before calling
objc_msgSendv(). It worked fine with all sorts of types,
including floats and doubles.
Really? That's exactly what I'm doing. For a test case I wrote a
class OCOCTestCall with a class method
I would have sworn under oath that I did the same thing... but
looking at the old CamelBones code in CVS, I see that it uses
NSInvocation. I may have done some experiments with marg_* &
friends, but if so I didn't check the code in - which is actually a
sign that I never got it working properly. I haven't touched the
older 0.2.x tree in almost 18 months though. Sorry for the
confusion. :-(
No sweat. To be honest, I'm relieved it didn't work for you either,
since I was pretty sure I was following the directions properly.
I did attempt to use marg_* & friends when switching to the 1.0.x
tree. The older version used simple message forwarding through a
proxy object. The current version registers Perl classes with the
runtime, so they're full peers that can participate in inheritance.
That's my next design decision. :-) I may start with a proxy object
and later try to achieve full bridging. I suspect it's tougher in
OCaml than in Perl, though, since OCaml doesn't have much support for
reflection.
The objc_msgSend() (& _stret) functions are used for messages from
Perl to native code. I call them using ffcall. I *tried* to use
objc_msgSendv(), but got tripped up when I wanted to call super
methods from within Perl subclasses. As I said, there's no "v"
version of msgSendSuper().
Registered Perl methods all share the same IMP, which examines its
self and _cmd arguments to figure out what Perl method to call. It
then uses the registered method signature and standard varargs
macros to pull arguments off the C stack and build up Perl's
calling stack.
Hmm. Good to know. I haven't figured out how to do the ocaml
dispatch yet. ffcall may come in handy there!
Hmm. I looked at libffi but the release notes said it didn't
support vararg functions.
I'm using ffcall, actually. Same idea though.
Neither one *directly* supports varargs. You have to know at run-
time (or be able to figure out) the number of arguments you're
passing to the function, and their types. But, if you do know that,
you can pass them to a function that's been prototyped as accepting
a variable number of arguments.
Oh, well that sounds like support for vararg functions to me. :-/ I
took a look at your code and ffcall is just what I've been looking
for! It's so tremendously useful! This stuff should really be part
of the C standard IMHO. If C is going to be the lingua franca for
programming languages it would be appropriate for it to support
programmatic construction of function calls.
I'll have to look again. Maybe I'll take a look at your code. :-)
Feel free - you might also want to have a look at the PyObjC and
RubyCocoa bridges.
I have looked at PyObjC a bit, but that was before I knew what I was
looking for. I've also looked at a Lua bridge that I'm now confident
doesn't work at all for floats because of its use of the marg_* macros.
Incidentally, I'm writing an Objective-C wrapper for OCaml, so
your code is more than a little bit relevant.
Cool - more options. Options are good. :-)
Spoken like a true Perlmonger. ;^)
The problem I found was that there's no "v" (at least none that's
documented) equivalent to the objc_msgSendSuper() function. What
I settled on doing was using ffcall to call the "normal"
msgSendSuper functions, rather than the marg_* macros and the "v"
functions.
if you have a pointer to the object's Class can't you use the
super_class field to get access to superclass methods? Maybe I'm
missing something?
You *could* do that, climbing up the class definitions until you
found the IMP to call, then using ffcall/ffi to call it directly.
I chose not to, because it's basically redundant. The objc runtime
already has all the code to look up a method, starting at a
particular point in the inheritance tree, and I didn't feel like
reinventing that wheel. Apple's wheel is likely to be rounder than
mine would be too - it's very efficient, and caches the results
from frequently-called lookups.
What's more, doing so wouldn't really save me anything - once I
found the correct IMP, I'd *still* have to use ffcall/ffi to call
it, with more or less the same code I'm using to call objc_msgSendv().
True.
Thanks for your help,
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/objc-language/email@hidden
