On Oct 4, 2013, at 12:50 PM, Greg Parker wrote:
> In practice you'll usually want to use NSObject*
Well *there* is a solution I would never have thought of in a million years.
I'm a bit surprised that so many built-in delegate properties in iOS (like, all
of them, many dozens) are typed as id
On Oct 4, 2013, at 11:30 AM, Tom Davie wrote:
> The more mathematically correct thing to do (and what it does for all other
> types) is “I don’t know what it is, so I can’t ‘prove’* anything at all about
> whether this is correct, therefore it’s not correct. Puny human, you must
> provide me
On Oct 4, 2013, at 20:30 , Tom Davie wrote:
> Right, really the confusion stems from the fact that objective-c has a
> strange behaviour when dealing with the type “id”.
Actually, “id” is not “strange” at all. It just uses the very simple Smalltalk
semantics: an object *always* responds to
On Oct 4, 2013, at 9:59 AM, Matt Neuburg wrote:
> Surely an id is, by definition, an id
It is not. There is no id-style type system leniency in `id`.
That type must conform to the protocol and respond to its methods, and nothing
more. Unlike `id` it does not allow use of any other methods.
In
On 4 Oct 2013, at 10:53, Jens Alfke wrote:
>
> On Oct 4, 2013, at 9:59 AM, Matt Neuburg wrote:
>
>> But why is either of those necessary? Surely an id is, by
>> definition, an id - which inherits from NSObject
>
> ‘id’ is not a type that inherits from NSObject. ‘id’ is explicitly untyped.
>
On Oct 4, 2013, at 9:59 AM, Matt Neuburg wrote:
> But why is either of those necessary? Surely an id is, by
> definition, an id - which inherits from NSObject
‘id’ is not a type that inherits from NSObject. ‘id’ is explicitly untyped.
‘id’ is _not_ untyped — its type is ‘any class that implem
On Fri, 4 Oct 2013 09:59:53 -0700, Matt Neuburg said:
>-(BOOL)test {
>return [self.celldelegate respond
>sToSelector:@selector(foo:)]; // ...wait for it...
>}
>
>Compile error! No known instance method for selector
>'respondsToSelector:'. WTF???
>
>Here are two ways of fixing the problem. (1)
> On Oct 4, 2013, at 9:59 AM, Matt Neuburg wrote:
>
> But why is either of those necessary? Surely an id is, by
> definition, an id
Nope. A couple years back the type of id was changed to only
respond to the methods in the protocol. This is arguably much more useful,
since otherwise the diff
On Oct 4, 2013, at 9:59 AM, Matt Neuburg wrote:
> Or, (2) inherit NSObject protocol back in the protocol definition:
>
> @protocol MyCellDelegate
> @end
You should do this.
> But why is either of those necessary? Surely an id is, by
> definition, an id
id is more specific than id, and so th
Here's a familiar pattern, a .h file defining a protocol and a delegate that
must adopt it:
@protocol MyCellDelegate;
@interface MyCell : UITableViewCell
@property (nonatomic, weak) id celldelegate;
@end
@protocol MyCellDelegate
@end
Here's the mystery. In the corresponding .m file:
-(BOOL)test
10 matches
Mail list logo
