Re: Creating an NSTimer subclass
Re: Creating an NSTimer subclass
- Subject: Re: Creating an NSTimer subclass
- From: j o a r <email@hidden>
- Date: Sat, 11 Nov 2006 23:55:45 +0100
On 11 nov 2006, at 13.55, leenoori wrote:
The problem is that there seems to be some sort of secret black
magic in the way that NSTimer and NSRunLoop interact. Even if you
implement all the public methods of NSTimer you'll still run into
these problems:
1. The method for scheduling a timer is not actually in NSTimer,
it's in NSRunLoop (addTimer:forMode:).
You are right, and I finally see what you're saying: If you need to
be able to use the timer as a drop-in replacement that can be passed
to NSRunLoop, it doesn't work to use my suggested approach.
I also toyed with creating a subclass to NSCFTimer, but it fails
since "self" is re-assigned to an instance of NSCFTimer when you call
super in init.
I would suggest that you file enhancement requests to Apple about
this. I think that the current combination of limitations seems a bit
unreasonable.
So I do think it is a problem that Apple's design makes it
difficult to subclass. Not just NSTimer but other Cocoa classes too.
I think that it's an advantage, as it promotes good design (and yes,
I know that's subjective). In languages where it's easy to subclass I
think that developers tend to create subclasses when they shouldn't.
For example, instead of having custom code in a window controller,
they would have it in a subclass to NSWindow. I think it makes a lot
of sense to leave the framework classes as is, and to contain your
custom logic to small subclasses to the root class (or other "thin"
classes that are designated to be subclassed, like NSWindowController).
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