Or I believe you can also do id< NSObject, MyProtocol > if you need
something that conforms to both. Unless you actually need something
that is only implemented in the NSObject class and not defined in the
protocol.
On Sat, Nov 27, 2010 at 11:35 AM, David Duncan wrote:
> On Nov 26, 2010, at 6:22
On Nov 27, 2010, at 9:46 AM, Andy Lee wrote:
> AFAIK protocols don't inherit from each other but rather conform to each
> other, meaning the above should be
>
> @protocol SomeProtocol
>
> But maybe I'm just unaware of new syntax in the latest compiler?
No, your probably right. Dangers of typ
On Nov 27, 2010, at 12:35 PM, David Duncan wrote:
> fortunately you can declare that your protocol inherits from another, and
> there is also an NSObject protocol that defines the core functionality of the
> class, so you can do this when you declare your protocol and never need to
> worry ab
On Nov 26, 2010, at 6:22 PM, Dave Zwerdling wrote:
> You can implement other methods and do a single cast to NSObject
> * (or id if you don't need the NSObject
> methods)
It is often impossible to get away from needing at least some of NSObject's
functionality, but fortunately you can declare
Thanks all,
I ended up changing around my object hierarchy and casting to a superclass that
has ordinals.
Mikkel
On Nov 26, 2010, at 10:38 PM, Julien Jalon wrote:
> Z) ignore the warning
>
> On Fri, Nov 26, 2010 at 9:44 PM, Ken Thomases wrote:
> On Nov 26, 2010, at 12:27 PM, Mike Abdullah wr
I always take the protocol route. You can implement other methods and do a
single cast to NSObject * (or id if you don't
need the NSObject methods) and then just pass around that. All you have to
check for in instantiation is that it passes implementsProtocol: and then
you're set. After that
On 26 Nov 2010, at 21:38, Julien Jalon wrote:
> Z) ignore the warning
>
Z^Z) ignore that
Regards
Jonathan Mitchell
Developer
Mugginsoft LLP
http://www.mugginsoft.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin
Z) ignore the warning
On Fri, Nov 26, 2010 at 9:44 PM, Ken Thomases wrote:
> On Nov 26, 2010, at 12:27 PM, Mike Abdullah wrote:
>
> > C) Typecast the object to a class that is known to implement -setOrdinal:
>
> D) Typecast the object to id.
>
> Regards,
> Ken
>
> ___
On Nov 26, 2010, at 12:27 PM, Mike Abdullah wrote:
> C) Typecast the object to a class that is known to implement -setOrdinal:
D) Typecast the object to id.
Regards,
Ken
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin
You have many options, in rough order of cleanness:
A) Declare a protocol that your objects conform to. Make -setOrdinal: @optional
B) Do [object performSelector:@selector(setOrdinal:) withObject:value] or use
-setValue:forKey:
C) Typecast the object to a class that is known to implement -setOr
I should have mentioned that it is declared, but obj can be one of many classes
only some of which have setOrdinal:
On Nov 26, 2010, at 6:46 PM, banane wrote:
> declare the method in your header file. "-(void)setOrdinal;"
>
> On Fri, Nov 26, 2010 at 9:08 AM, Mikkel Eide Eriksen
> wrote:
> Hi
Hi all,
I have the following bit in my code:
if ([obj respondsToSelector:@selector(setOrdinal:)]) {
[obj setOrdinal:value];
}
XCode gives a warning that obj may not respond to setOrdinal: which won't be a
problem unless something is really screwy. But how do I get rid of the warning?
O
12 matches
Mail list logo