Re: Protocols on the fly?
Re: Protocols on the fly?
- Subject: Re: Protocols on the fly?
- From: Owen Anderson <email@hidden>
- Date: Mon, 28 Apr 2003 19:51:29 -0400
You've both made some very good points about it. Now, here's my final
take:
Sherm is probably right that it's not really necessary. However, I
would like to make the object transferral as transparent as possible.
If I could handle the protocol myself, I would like to. Again, it's
not imperative, but would be nice.
Now, I think I've figured out a way to achieve this.
--COMPILE TIME--
1) Framework cross declares the Protocol class as a struct using @defs,
which allows its insance variables to be accessed as a struct
--RUN TIME--
2) Object is passed to framework
3) Framework calls [Object class] and stores it in Class
4) Framework instatiates a protocol object called Protocol
5) Protocol->instance_methods = Class->methodLists;
Protcol->protocol_list = Class->protocols;
Protocol->name = "Object";
6) Pass the Protocol object to the client by some means, and then the
client applies this to the DO when it receives it.
Would that work?
Owen Anderson
On Monday, April 28, 2003, at 07:21 PM, Sherm Pendley wrote:
On Monday, April 28, 2003, at 06:48 PM, John Hvrnkvist wrote:
On Tuesday, Apr 29, 2003, at 00:30 Europe/Stockholm, Sherm Pendley
wrote:
You'd only need to declare a protocol if your framework were *not*
transparent - that is, if it expected the objects it receives to be
able to handle a particular set of messages. In that case, you'd
want to declare those methods in a protocol and verify that any
objects it handles conform to that protocol.
There is more to it than that; by setting a protocol for a proxy, you
decrease the number of round trips. If there's no protocol set for
the proxy, it has to query the remote object for the method >> signature.
Yes, if your code sends any messages to the remote object, those
messages should be declared in a protocol. But in that case, the
framework would not be transparent - it would expect the remote
objects to be able to handle the messages sent by the framework. I
think Owen's writing a completely transparent framework - the
framework itself doesn't send any messages to the remote object, it
simply hands off any objects it receives to the host application.
The host application in this instance would, of course, want to
declare a protocol of the messages it wants to send. But, that's part
of the host application, not Owen's framework.
I'm assuming that Cocoa's default NSProxy is well-designed, of course,
and queries for method signatures only when they're actually needed to
send a message. As you said, avoiding unnecessary network chatter is
important, and querying a distant object for method signatures that
may never be used would be wasteful.
sherm--
C programmers never die - they're just cast into void.
_______________________________________________
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.
_______________________________________________
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.