[Openmcl-devel] Why .cdb instead of method_getTypeEncoding for cocoa?

[Gary Byers]

Up until a few years ago (around the time of the 1.0 release, give or
take) that's how things worked: the bridge queried the ObjC runtime
for the set of all classes that existed and queried each class for
the set of methods and instance variables that existed in the runtime
world, parsing the type strings associated with the methods and ivars.
There were 3 reasons (that I can think of/remember) for changing that:

1) The universe of all classes/methods/instance variables in the
runtime world varied between dot releases (so an application saved
on 10.4.1 had a model of the world that didn't necessarily match
the world it found when it tried to run in 10.4.2)  That model
included things like the CLOS class hierarchy, and we tried to
model the fact that NS:_NSGawdAwfulInternalClass was a subclass
of NS:_NSNotSoBadInternalClass; internal classes and their relationships
changed between dot releases, and it wasn't clear to me that there
was a good way to reconcile the model of what had existed at build
time with what was found at runtime; saved images would just quit if
the AppKit or Foundation library version numbers on startup didn't
match the versions available when the image was saved.  (That was
actually better than not addressing the problem would have been; I
never saw a particularly good approach to addressing the problem.
Part of what made that difficult is that we had no way of knowing
what differences between the save-time and load-time worlds were
significant and which weren't.)

The problem becomes a lot simpler/more tractable if we treat
"declared classes" (and their methods/slots) differently than
"undeclared classes"; if the CLOS model is based on the intersection
of what we exepect to be there (is declared to be there) and what
actually is there (in the runtime), it's smaller, more tractable,
more accurate, and less sensitive to irrelevant changes that occur
between dot releases.

Once we had interfaces that describe what classes are declared,
we could also use the interfaces to describe method and slot types,
avoiding some of the problems with type encoding.

2) ObjC's scheme for encoding types loses information: the type
:<BOOL> is encoded the same was as :char is, and it's obviously
desirable to be able to treat these foreign types differently.

3) The scheme by which ObjC types are encoded is obscure, baroque,
largely undocumented, and changes over time.  (Tiger started including
some classes and/or methods that were apparently generated by the
ObjC++ compiler, and we had difficulty parsing the type encodings.
Maybe that could have been fixed, but there'd likely be something
else that broke soon after.

A fourth reason is that the current scheme allows for faster
startup times than the old scheme did; that wasn't part of the
motivation for the change, but it's a nice bonus.



On Fri, 16 Nov 2007, Raffael Cavallaro wrote:

> Maybe (probably) this question has been asked and answered before, but
> why parse headers and create an interface database for cocoa
> frameworks rather than just load the framework and query the runtime
> itself?
>
> regards,
>
> Ralph
>
> Raffael Cavallaro, Ph.D.
> raffaelcavallaro at mac.com
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>