Objective-C and runtime type inspection

Bob Ippolito bob@REDACTED
Thu Aug 17 21:38:59 CEST 2006

On 8/17/06, Joel Reymont <joelr1@REDACTED> wrote:
> On Aug 17, 2006, at 8:14 PM, Bob Ippolito wrote:
> > varargs is not covered by type encodings, it looks like a single
> > object. You simply can't know that it's supposed to be nil terminated
> > varargs.
> Pain in the rear, yes. So long as one can build a varags list by hand
> in C (I think you can)  it would still be manageable, though. You
> would just give objc_msgSend the object, the selector and then the
> varargs list built from the arguments list.

We use libffi for that. The version in the PyObjC repository is
patched to work on Mac OS X Intel (I don't think the official one
supports that yet).

> > Well, all you know its that it's an id pointer and an integer, not
> > that it's supposed to be an array of id plus exactly the length of
> > that array.
> I guess it would be up to the programmer to make sure that proper
> arguments are given. I figure I can pass structures as binaries and
> pointers as ints.

What about a pointer to a structure, output structures, input/output structures?

> > Probably better off with just using atoms to represent selectors
> > instead of generating a million functions. Maybe something like:
> >
> > msg(Self, Selector, [Args]) -> ...
> >
> > Which is basically the same as objc_msgSend except using a list
> > instead of varargs.
> Yes, that's exactly what I'm thinking about. I also want to make the
> Obj-C runtime a driver as opposed to a C-node. I don't want the
> networking overhead but I'm easily swayed.

The networking overhead is going to be irrelevant for the most part.
None of the messages in a typical Cocoa app are big unless they're
creating NSBitmapImageRep from memory or something. I'd make it a
C-node personally.

> > I really do hope you choose to make the objc binding open source,
> > because if you don't someone else is going to have to duplicate the
> > work eventually.
> Yes, I'll release them under the Erlang license. With everyone
> reviewing the code and trying out it will go much faster.



More information about the erlang-questions mailing list