I really appreciate the work you're doing on corebase. I really haven't had any time to do anything recently, but I have been keeping up with your changes.
Personally, what I would like to see is an agglomeration of all the related projects. For example, why can't the corenetwork library be brought into corebase? No reason why these 2 libraries are split. To answer your question, I think that sounds fine, but why not just override NSRunLoop's designated initializer and just return NSCFRunLoop (or whatever you want to call it)? Wouldn't that be easier than checking for a symbol? Or am I missing something? On Mon, Feb 3, 2014 at 2:45 PM, Ivan Vučica <ivuc...@gmail.com> wrote: > 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 > >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
