Re: [iPhone] Why can't a UITextField be its own delegate?
Re: [iPhone] Why can't a UITextField be its own delegate?
- Subject: Re: [iPhone] Why can't a UITextField be its own delegate?
- From: WT <email@hidden>
- Date: Sun, 26 Jul 2009 00:54:26 +0200
On Jul 26, 2009, at 12:41 AM, Adam R. Maxwell wrote:
On Jul 25, 2009, at 3:23 PM, Kyle Sluder wrote:
Internally, UITextField is going to use self.delegate to get its
delegate, following the correct accessor behavior. You've gone and
replaced -delegate to return self. But the delegate pattern says
that
messages which this object does not understand should be forwarded to
the delegate. This means that a class with a delegate needs to
implement -respondsToSelector: this way:
- (BOOL)respondsToSelector:(SEL)aSelector {
return [super respondsToSelector:aSelector]
|| [self.delegate respondsToSelector:aSelector];
}
Where is this guaranteed by the delegate pattern? I've created a
fair number of classes with delegates and never done this; it would
be interesting to know that I've been doing it wrong for years ;).
Good point!
Since -delegate is going to return self, -respondsToSelector: is
going
to result in infinite recursion.
So It's Never Safe To Make An Object Its Own Delegate.
Even if it's safe, it's a bizarre way to do something, especially if
you're already subclassing it...especially since delegates are
mainly used to avoid subclassing.
As I pointed out earlier, the common work that needs to be done
consumes the delegate outlet. Thus, any extra work that would
otherwise be done by a delegate requires an outlet for that outside
delegate. I simply wire things up internally so that the work is
chained while, to the outside world, it still looks as though there is
only one delegate.
For the specific case of limiting text field input, why not just use
an NSFormatter subclass, though? That's what I'd do in Cocoa (and
this is the cocoa-dev list, after all).
Ok, that's an idea I hadn't thought of and worth exploring. Thanks for
the suggestion.
Wagner
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden