well the first one just says that anObject supports the protocol and
it tells you NOTHING else about it at all. So the only methods you can
call on it without having the compiler warn you that they may not
exist (and they may not exist) are <Protocol> methods.
Seems fine until you actually try it in code and you realise you want
to call retain or release or observeKeyValue ... etc. and you get a
load of compile errors because the 'normal' methods you expect aren't
there.
So the second one says that the parameter is an NSObject subclass
which supports the <Protocol> protocol, which means you can call all
the usual NSObject things on it. It means you have to pass something
which is an NSObject subclass but that's not unusual, most things are
right?
The NSObject methods are so ubiquitous that I pretty much always use
the second form when I'm using a protocol because I almost always want
at least some NSObject methods, like release/retain.
If you have yet stricter requirements, say you have some class which
supports a shape, MyShape and you have a Drawable protocol then you
may well use a parameter declared as MyShape <Drawable>*, which means
you guarantee that the parameter is a MyShape subclass (so you can
call MyShape methods on it) and it's also Drawable.
As NSObject is also a protocol you could probably also do
id <NSObject, Protocol> to say the object supports NSObject and
Protocol methods but I never do, partly because it doesn't seem as
clear, partly because I know that I'm always going to pass something
which is actually descended from NSObject, not just supporting that
protocol and partly because the NSObject protocol doesn't have some of
the NSObject methods I often end up using.
On Mar 14, 2009, at 12:13 PM, Richard Somers wrote:
The Objective-C 2.0 Programming Language documentation indicates
that a type declaration for an object including a formal protocol
should look something like this.
id <Protocol> anObject;
I have been studying some sample code that does it like this.
NSObject <Protocol> *anObject;
What is the difference between the two?
Richard
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
This email sent to r...@rols.org
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
