DO: Protocols and Categories don't play nice
DO: Protocols and Categories don't play nice
- Subject: DO: Protocols and Categories don't play nice
- From: AgentM <email@hidden>
- Date: Mon, 6 Oct 2003 22:20:31 +0200
I am using DO between threads to perform selectors in a "manager"
thread (the progger passes an object in to be handled). To reduce the
overhead of DO (as per the Apple Docs), I wish to supply a protocol.
Unfortunately, I don't have a protocol to set but I do know the object
definition which is composed of multiple categories across a number of
source files (because it's big). All of the selectors would be of
interest to the manager thread and thus should be part of the protocol.
The way I see it, I have some choices (one of which doesn't seem
possible):
1. Write the protocol manually and try to keep it in sync with the rest
of my code for that class. OR create the class which is to be managed
as conforming to the protocol that I create. But how can I do this
while preserving the code organization across multiple categories? (I
won't be warned when I add extra methods to the class either and forget
the protocol. I confirmed that protocols only check for conformance in
the main definition of a class using a simple example.)
2. Write a runtime generator to iterate over objc_getClassList(...) to
generate a protocol at runtime. The Apple Docs however state that:
"Protocol *counter = @protocol(ReferenceCounting);
This is the only way that source code can conjure up a Protocol object.
Unlike a class name, a protocol name doesn't designate the
objectexcept inside @protocol()"
"Only" is pretty definitive here, I guess that idea is dead.
3. Don't set a protocol and incur the overhead albeit, always within
the same process. This isn't preferable because the purpose of the
manager thread is to simulate a non-blocking network interaction and I
don't like the idea of waste that I can avoid (I know which selectors
are valid! Can I subclass NSConnection to avoid the selector check?)
4. Give up on DO and make my manager a proxy forwarder of the objects
it manages. I could then communicate over a regular port sending the
SEL (along with an object "id") to the select()ing thread.
5. ???
Am I missing something? How are other people doing this? Right now, it
looks least complicated to consolidate my categories into a monster
definition. Sorry for the long mail- I *really* don't want to give up
my categories....
P.S. As a lazy but efficient progger, I would prefer #2, but I am
afraid that that is just a pipe() dream.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.