On Aug 11, 2005, at 3:33 PM, Nathaniel Gray wrote:
On Aug 11, 2005, at 9:40 AM, Sherm Pendley wrote:
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.
Perl's not terribly robust in that area either, actually. I had to
fake it. Perl has a notion of "subroutine attributes" - essentially
named values that are passed to a handler routine during compilation.
They look like this:
sub foo : Attribute(value) {
}
What I did is use this feature to give Cocoa/Perl programmers a way
to declare the selector, arguments, and return type of a Perl
subroutine. This information is stored in a lookup table that's in
the package in which the function was defined, along with a reference
to the function itself. The key to the lookup table is the selector.
Standalone code - i.e. code outside of any sub definitions - is run
immediately after a Perl module is compiled. So, I provided a "class"
function that reads the structure that was built up from the
subroutine attributes, and registers the Perl class with the
Objective-C runtime.
At run time, when the Perl IMP is called, it gets the class of self
to find the package in which to find a lookup table. If it finds a
lookup table, it uses the _cmd to search in that table for the
corresponding Perl function.
Hmm. Good to know. I haven't figured out how to do the ocaml
dispatch yet. ffcall may come in handy there!
Perl has a "fallthrough" function called AUTOLOAD that's similar in
spirit to Objective-C's -forwardInvocation: method. I implemented
this function is the NSObject package, so that any method that's not
defined in Perl gets caught, and handled by being dispatched to
Objective-C.
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. :-/
Yeah, I think the authors are *really* being too picky by disclaiming
varargs support.
I understand what they mean though - for instance, if you want to
call something like printf(), you can't simply pass the format string
and second argument, and expect ffcall to figure out the rest of the
arguments for you. You have to explicitly pass all of the arguments,
each one with the correct type-specific macro.
One real limitation is that it doesn't support structure return
types. But the Objective-C runtime provides a neat way to dodge that
issue entirely, by simply calling objc_msgSend_stret(). Come to think
of it, that's the main reason I use objc_msgSend(). Originally, I was
doing what you mentioned, looking up IMPs and calling them directly.
But correctly handling structure returns was proving to be a pain, so
I deleted all the IMP lookup code and let the runtime handle at. It
turned out to be a much simpler solution.
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.
FFI is actually part of the GCC distribution, although for some
reason Apple didn't opt to include it. I didn't really feel like
building my own GCC just to get a copy of libffi, so I went with
ffcall instead.
FWIW, I've used Apple's "Universal" SDK, GCC 4, and a combination of
the --build, --host, and --target configure options to cross-compile
a i386 version of ffcall. Then I used lipo to weld that together with
the ppc version into a "fat" library. I've no way to test the results
however, as I don't have an Intel Mac to play with.
_______________________________________________
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
