Objective-C and runtime type inspection

Bob Ippolito <>
Thu Aug 17 21:14:50 CEST 2006

On 8/17/06, Joel Reymont <> wrote:
> On Aug 17, 2006, at 7:37 PM, Bob Ippolito wrote:
> > You'll still likely have problems with varargs and paired
> > arguments, e.g.
> > +[NSArray arrayWithObjects:...]
> I don't remember off hand how this case is handled but all functions
> have a definite type signature. Maybe the varargs go in as an array
> or something. I'll need to inspect NSArray.

PyObjC is by far the easiest way to poke at this stuff...

$ python
Python 2.4.3 (#1, Apr  7 2006, 10:54:33)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Foundation import NSArray
>>> NSArray.arrayWithObjects_.signature

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

> > and +[NSArray arrayWithObjects:count:].
> This is an easy case because the selector (method name represented as
> a string) is exactly "arrayWithObjects:count:".

>>> NSArray.arrayWithObjects_count_.signature

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 didn't think of it this way but I can try going totally dynamic. I
> could do RTTI the first time a selector is invoked and cache the info
> in a dict, gb_tree or ets table.

That's sort-of what we do in PyObjC. We do it for a whole class at a
time, but same idea.

> The whole point of importing or parsing headers is to generate
> functions whereas Erlang, just like Objective-C, works by message-
> passing.

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.

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.


More information about the erlang-questions mailing list