(The source to class-dump isn't going to help for *in runtime*
introspection; it works by ripping apart the mach-o segments and dumping
the ObjC stuff. Certainly, could be done from within the running app to
itself, but that won't truly tell you what is going on at the runtime.
The runtime is dynamic and there are many more classes than just those
immediately present within your mach-o.)
Some other tips before buggering the runtime....
- method swizzling is a beautiful and dangerous thing. See the source to
PBXNoSlideHack and SSHPassKey (the PBX bundle) for examples of swizzling
(swapping one method's IMP for another). It can be dangerous in that you
can easily hose the app by making assumptions that just ain't true. (Also,
it is particularly confusing to implement a method and have to remember
that self in the body of the implementation does not actually point to an
instance of the class you implemented the method in...)
- When working at the objc_*() API level, you are far better off treating
everything as pointers to C structures. Instead of converting a Class to
a string (NSStringFromClass() or via "%@"), use %s and the isa->name. In
general, the fewer objects you create or message when down in the bowels
of the runtime, the better off you will be.
- As John indicates, certain classes do not behave like NSObject. I
would state a bit more strongly; certain classes do not want to be
touched, ever, outside of the context they are implemented to be used
within. NSProxy is an example; any attempt to message the class directly
will generally yield an exception. Faults are another. There are a
handful of others. They will make themselves abundantly apparent when you
run into them.
- Transparent bridging between ObjC and CoreFoundation makes things tricky.
I.e. sometimes an NSString or NSBundle is not really a Foundation object,
but is a CFStringRef or CFBundleRef that can be transparently messaged,
but doesn't behave *quite* like an ObjC object when you start doing weird
things to it.
- There used to be some bugs in the AppKit related to class initialization
order. That is, if you walked down the list of classes as returned by
objc_getClasses() and messaged each class, you would cause the +initialize
to be called. Certain classes (Font related, if I remember correctly)
didn't like to be initialized before others. These were mostly fixed, at
one point, but there have been numerous changes since OpenStep 4.2 and
there may be new ones.
- You can programmatically create new classes without much difficulty
(outside of remembering all that 200 level C pointer stuff), register them
with the runtime, and use them like any other ObjC class. This is how
various intra-language bridges often work.
The bottom line is this: If you stick to the APIs as perpetuated by
NSObject for performing introspection, the runtime will generally behave
in a clean and controlled fashion as any good dynamic runtime should (i.e.
think SmallTalk, Python, Common Lisp). However, when you dive into the
depths and drop down to the objc_*() functional API for manipulating the
runtime directly, you are going to run into a number of optimizations or
other bits of magic that behave much more like a highly optimized ANSI C
based implementation (i.e. confusing) than like a well disciplined,
totally consistent, runtime.
This is not a criticism-- the optimizations and other hackery are there to
make programming against the pure object APIs that much more enjoyable /
flexible / effective. And they generally do and do so in a relatively
efficient fashion in comparison to other runtimes and without sacrificing
too much in the way of flexibility.
b.bum
On Tuesday, January 15, 2002, at 08:58 PM, cocoa-dev-
<request...> wrote:
> Take a look at /usr/include/objc/objc-runtime.h. (objc_getClassList)
>
> Note that not everything that is a class has to behave like NSObject or
> Object; be careful to check that the class is something you know how to
> handle before you start sending messages to it.
>
b.bum
I ride tandem with the random....
.... things don't happen the way I planned them.
