On Jul 25, 2009, at 11:44 PM, Kyle Sluder wrote:
On Sat, Jul 25, 2009 at 1:14 PM, WT<[email protected]> wrote:
This particular text field needs to limit its number of characters
to a
given interval. Why should any other object have to deal with that
problem
when the field itself can take care of it? Still, it might be the
case,
though it also might not be the case, that another object wants to
participate in the editing session. The flow of events here is as
follows:
the field takes care of its own business first (limiting the number
of
characters) and then allows the delegate, if any, to have its shot
at the
editing process.
In the Cocoa world, it makes more sense to hook up a delegate to do
this work, especially if this is a one-off control. It comes down to
thinking of it as "a text field which limits number of characters"
rather than "a number-of-characters-limited text field". If you need
this behavior in multiple places in your application, you can factor
out the delegate behavior into a superclass and have your delegates
derive from it, calling this method when necessary.
What if the delegates are already subclassed? Since multiple
inheritance is not an option, the code that limits the number of
characters would have to be repeated in several places.
On Jul 25, 2009, at 11:20 PM, Luke the Hiesterman wrote:
If you simply called your new delegate something other than
"delegate" - like "myCustomClassDelegate" or whatever then it
wouldn't be convoluted. But overloading self.delegate is not a good
idea at all.
This custom text field is still a text field in every way. It simply
performs some work between the editing done by super and the editing
done by the delegate.
There is no reason for any outside entity to want to refer to
super.delegate. In fact, unless I'm wrong, I don't think it's even
possible to retrieve super.delegate from the custom instance.
My understanding is that super is not an object but merely a
"directive" to the compiler instructing it where to start the search
for a method implementation. Moreover, all delegate methods are
implemented by the custom class and they all query the outside
delegate as needed.
Thus, as far as any clients of the custom class are concerned, a
delegate of the custom instance is as true a delegate as the delegate
of any non-subclassed UITextField. There is no way, as far as I can
see, that an outside entity could ascertain that the delegate reported
by calling -delegate is not the true delegate.
Also, I think it would be confusing for a client of the custom class
to have to set itself as a custom delegate when it's trying to do what
it would normally do as a regular delegate. Moreover, what would
prevent it from setting itself up as the true delegate? Given the
choice of calling -setDelegate and -setCustomDelegate, what would one
do?
The way I'm doing this, everything is as transparent as possible. You
call -setDelegate to set yourself up as the delegate just as you would
if this text field was a regular UITextField, and when you call -
delegate you get the correct object as well.
The custom class is then a perfect replacement for a regular
UITextField. Other than replacing [[UITextField alloc] init] with
[[CustomTextField alloc] init], there are NO changes to client code
anywhere.
Can you give me an example of a situation where this might be a bad
idea? I really can't see any.
Wagner
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
