Re: Creating an NSTimer subclass
Re: Creating an NSTimer subclass
- Subject: Re: Creating an NSTimer subclass
- From: j o a r <email@hidden>
- Date: Fri, 10 Nov 2006 22:58:20 +0100
On 10 nov 2006, at 12.13, leenoori wrote:
You would schedule the wrapped timer object, and not your object
instance.
Unfortunately then it's not longer a drop-in NSTimer replacement,
but would need some special way of being scheduled... eg a method
on the timer subclass itself like "schedule:forMode:" or whatever.
I don't get what you're saying. Your custom class (not a timer
subclass) would implement all methods from the NSTimer public
interface, so you would in fact be able to use it as a drop-in
replacement. No need to add any new methods to the interface at all.
On 10 nov 2006, at 18.54, leenoori wrote:
Yes, I can do that: I want to add two convenience methods, "pause"
and "resume", and I need some instance variables in order to
implement them. Pausing is done by setting a fire date in the
distant future. Resuming is done by putting the fire date back
again after adjusting it to take into account the time elapsed
while paused. Instance variables are required because the timer
needs to remember the old fire date, take into account how long it
has been paused, and adjust the old fire date accordingly.
So there is actually really no requirement to have you subclass work
as a "drop in replacement" at all? If you're just using it for your
own code, you could just as well have something that's abstracted and
enhanced to serve your particular needs.
The methods are really just convenience methods for something that
I've found myself wanting to do at various points of the years. And
each time I've done it I've ended up writing auxiliary helper
methods in the controllers that use the timers with names like,
"startTimer", "stopTimer" etc. Rather than do this yet again, I'd
like to encapsulate the behaviour inside the timer itself. This is
a pretty logical thing to want to do with a timer, I think.
Be a bit pragmatic. If you fail to subclass in this particular case,
take another route. I could have wrapped NSTimer in a custom class to
provide the functionality you're asking for in much less time than
what we've spent reading and writing messages in this thread.
That said, if you consider this a great limitation, I would suggest
that you file an enhancement request with Apple.
I think it highlights a problem that often crops up in the Cocoa
frameworks: you want to augment the behaviour of a Cocoa class in
an extrememly minor way, a mere tweaking of the behaviour, but the
framework prevents you from doing the logical, simple, object-
oriented thing (making a subclass) and you instead either have to
reimplement the class from scratch or engage in some hideous
kludgery, making it less of a refined subclass and more like a
twisted mutant offspring of the parent.
I don't agree that subclassing is such a great way to introduce new
functionality. Class hierarchies should remain shallow. There are any
number of alternative design patterns to choose from without having
to resort to "hideous mutant kludgery".
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden