Re: Protocols on the fly?
Re: Protocols on the fly?
- Subject: Re: Protocols on the fly?
- From: Sherm Pendley <email@hidden>
- Date: Mon, 28 Apr 2003 18:30:02 -0400
On Monday, April 28, 2003, at 04:20 PM, Owen Anderson wrote:
Now, when transferring objects over DO, it is highly recommended that
you provide a Protocol to assign to it once it reaches the client.
It's important to understand *why* using a protocol is recommended for
DO - that way, you'll know when the recommendation doesn't apply to what
you're doing. It's not a requirement, after all - you can ignore it if
you want. Ignoring it often means either taking on more work or writing
unsafe code, but not always. In some situations - such as the one you
find yourself in, I think - it would mean a lot of work for little or no
benefit.
Protocols allow stronger type-checking than you could otherwise do with
objects that are declared as just id. You declare objects of type
id<protocol_name> instead, and the compiler can then check the types of
arguments and return values you use when you call methods declared as
part of the specified protocol.
At run-time, if you have defined a protocol and you want to verify that
an unknown object conforms to it, you can send the object a
conformsToProtocol: message. It's simpler than checking each method
separately by sending a lot of respondsToSelector: messages. It's also
more comprehensive - in addition to checking that the object responds to
the expected selectors, it also checks that the argument and return
types of the declared methods are as they're expected to be.
A dynamically-generated protocol would not be available at compile-time,
eliminating the first use. And the second usage makes no sense; if the
protocol is being generated on the fly from the object, then naturally
the object will *always* conform to the generated protocol.
However, I want my framework to be as transparent as possible, and
preferable not force my host applications to provide me with a
protocol.
Then don't use one. Protocol usage in DO is meant to be a convenience,
not a burden - it allows for easier type- and sanity-checking, but a
transparent framework that simply passes arbitrary objects along to its
host application has no need for that sort of checking. That's why it's
recommended to use a protocol, but not required - it's not always useful.
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.
sherm--
"But i don't want to go among mad people," Alice remarked.
"Oh, you can't help that," said the Cat: "we're all mad here. I'm mad,
You're mad."
"How do you know I'm mad?" said Alice.
"You must be," said the Cat, "or you wouldn't have come here."
"Alice in Wonderland" - Lewis Carrol
_______________________________________________
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.