Re: @protocol vs NSClassFromString
Re: @protocol vs NSClassFromString
- Subject: Re: @protocol vs NSClassFromString
- From: Jim Correia <email@hidden>
- Date: Tue, 21 Jan 2003 21:45:53 -0500
On Tuesday, January 21, 2003, at 09:29 PM, The Amazing Llama wrote:
I understand that these two things are fundamentally different in
results, but they are quite similar in what they do; query the > runtime.
So why isn't it @protocol and @class()? This makes more sense to my
intuition, and is a hell of a lot shorter...
The definition always has to be available at compile time. If you write
Protocol *proto = @protocol(SomeNonExistantProtocol);
and SomeNonExistantProtocol isn't available in the include chain, you
can't compile your code.
In other words, you shouldn't get back nil from @protocol.
NSClassFromString can find a class at runtime that you knew
nothing/little about at compile time (and is in fact how the principle
class is loaded from a bundle for things like the screen saver, etc. -
usually checking that the principle class is a subclass of a
pre-defined class or conforms to a given protocol...)
If the class cannot be found at runtime, nil is returned. There is no
compile time check here.
Jim
_______________________________________________
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.