On Tue, 4 Feb 2014 08:45:32 +0000, David Chisnall wrote:
On 3 Feb 2014, at 23:14, Luboš Doležel <lu...@dolezel.info> wrote:
I looked into it again:
"Methods defined in categories can replace methods defined in the
class
proper, but they cannot reliably replace methods defined in other
categories."
I suppose this could be good enough after all. I wouldn't expect any
other NSRunLoop overrides around.
The problem is that if someone else provides a category in a shared
library, there is no guarantee whether yours or theirs will be loaded
first, and it depends entirely on link / load order so may not be
stable.
However, I'm not sure I understand why this is an issue for
CFRunLoop. The CFRunLoop is roughly analogous to GSRunLoopCtx, and
so
the right way of doing this would be to rename GSRunLoopCtx to
CFRunLoop, clean up its APIs, and make it public. There are multiple
implementations of this currently, and it would also be nice to have
one that used libdispatch at the core so that we could use
libdispatch's main queue as the main thread and so on.
I'm afraid The only thing that CFRunLoop and GSRunLoopCtx have in
common is that there is some kind of loop.
The way I understand CFRunLoop, it doesn't actually poll for a set of
fds, CFRunLoopSources version 0 do this on their own in a separate
thread (or a libdispatch queue). CFRunLoopSources version 1 are used for
Mach ports only - CFRunLoop polls these, but I don't think we can swap a
Mach port for an fd.
You're right, libdispatch would be great for this. But what I fear is
that as soon as I start working in that direction, someone will come and
either start complaining about a libdispatch dependency or Clang
requirement once I dare to use a block. And the last thing I would do is
to write one worse implementation for GCC and one nice implementation
for Clang.
So one thing we should be clear about is whether we approve of CoreBase
being a project where we strive for nice modern implementations *or*
whether we still cringe to legacy compilers and the
provide-fallback-for-every-dependency strategy.
--
Luboš Doležel
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
