I like the plan, and in context of Core Animation, I highly appreciate it. I'd also love to, long-term-but-as-soon-as-possible, see such a toll-free bridged implementation become the primary implementation.
On Mon Feb 03 2014 at 5:14:05 PM, Luboš Doležel <lu...@dolezel.info> wrote: > Hi, > > I've started pushing more code into corebase (CFStream implementation, > not thread safe for now) and did some very initial work in corenetwork. > Unfortunately, I can't complete my work until CFRunLoop is functional. > > I've worked hard on toll-free bridging, with most common types already > bridged by now. One of the biggest remaining hurdles is the lack of > integration between NSRunLoop and CFRunLoop. These two are not toll-free > bridged, NSRunLoop is rather supposed to be implemented on top of > CFRunLoop, as CFRunLoop is much more powerful. > > Now, since NSRunLoop is a very important component of the whole > ecosystem and I think we want to avoid the dependency of gnustep-base on > corebase (it would form a loop, and corebase is neither complete nor > extensively tested), I think the right way forward would be to add a > second implementation of NSRunLoop that would only be used if corebase > is loaded by the application. I'd call it NSCFRunLoop, for example. > > My idea would be to use a weak reference to CFRunLoopGetCurrent() and > somewhere in NSRunLoop's initialize make a permanent decision, which > implementation to use based on CFRunLoopGetCurrent being NULL or not. > > It will take me some time to get to this point, but first I'd like to > hear your thoughts. > > Regards, > -- > Luboš Doležel > > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
