On 1/17/07, Quentin Mathé <[EMAIL PROTECTED]> wrote:
> 2) Writing a GObjectWrapper class, that would use > forwardInvocation: to pass on messages to the corresponding > functions. This would lose us any kind of nice type checking, but > would be relatively clean, assuming GObject stores enough > information to get method names at runtime...
I don't think they store any method name with GObject. All should be gone at compile time, just like C++.
> 3) Modifying the GNU Objective-C runtime so that it does this > mapping for us, and lets us use GObjects as Objective-C objects > directly. This would be ideal, but it would require some > significant modifications to the objc_msgSend mechanism. Ideally, > if I were to do this, I would wrap around the objc_object structure > up in something that would include an object_type element. This > would then contain a set of function pointers to equivalents of > objc_msgSend, thus allowing us to add support for future object > representations, but it would break binary compatibility with > absolutely everything...
So this shouldn't be possible since there is no isa like thing and so you sholdn't be able to map a selector to any method. But you may want to recheck the facts. However, I think parsing the header files isn't a bad idea! My most recent design of Maliwan aims to support GEGL nodes in a way. (probably by using available visitors or properties) and not relying on any kind of dynamic method binding. IMHO, if something was intended to be C in first place, it then should always be C. And that's why we have "C" hanging after "Objective". But you know, I have been suffering reading IMP caching code in GNUstep :) I'm rewriting NSRunLoop to use GLib, however. It is in my experimental fork of -base called "Coincide" in case that you've noticed that. But you should just get around that using GSRunLoopWatcher to wrap GLib runloop rather a full rewrite like Coincide's way. (It isn't neccessary to have your runloop over GLib just to use glib runloop, but gnustep's runloop is incompatible with me in too many ways to continue working with.) Anyway, I plan to rely on GLib datatypes in future, only in my tree and without exposing them. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
