Re: What is the best way to get an NSSlider to respond to the mouse scroll wheel?
Re: What is the best way to get an NSSlider to respond to the mouse scroll wheel?
- Subject: Re: What is the best way to get an NSSlider to respond to the mouse scroll wheel?
- From: Bill Bumgarner <email@hidden>
- Date: Thu, 27 Nov 2008 21:09:50 -0800
On Nov 28, 2008, at 12:19 PM, Graham Cox wrote:
On 28 Nov 2008, at 11:46 am, Bill Bumgarner wrote:
At best, your app's standard sliders will behave in a decidedly non-
standard fashion. At worst, your app's standard sliders will crash.
Could you explain how that's a real possibility? I don't see that.
Sure.
Secondly, if my category takes effect then it will override Apple's
implementation anyway, so I'd see no difference *in my app*. It
might differ from other apps, but it already does in that other
apps' sliders don't respond to the scrollwheel. Also, if Apple were
to add this method to NSSlider, surely it would just be part of the
class definition for it, rather than in a separate category? If so,
my category would always prevail. If it were added in a category, it
would be pot-luck whose version prevailed, which is certainly
undesirable, but not exactly unsafe, as such.
I can't envisage a realistic scenario where a crash could occur, but
do enlighten me as I'm certainly not familiar with every pitfall here.
You are assuming that the implementation of the method is fully self
contained. There are any number of reason's why the implementation
of such a method may rely upon state maintained by other methods or,
more importantly, might adjust some internal state in the object that
is later required.
This may be done for optimization reasons or it could be done to
support some new bit of hardware (the growing pool of multiple finger
trackpad gestures come to mind).
The bottom line is that you cannot safely assume that method -x of
class Y has zero dependencies the behavior of other methods in the
class. Nor is there any way for you to know, short of disassembling
specific versions that may change in the future, that you have
discovered and are correctly handling all such dependencies. Even if
you could, it can change in future implementations.
This isn't just fear mongering. In the nearly 20 years (sheesh! I'm
old!) that I have been actively writing / maintaining / debugging
Objective-C applications, I have seen a number of situations where
crashes and misbehaviors were due to categories overriding methods
provided by system classes. It doesn't happen often, but it
definitely does happen and, worse, when it does happen the resulting
behavior is often really really bad. Data loss kind of bad.
What use is it, if it's such a bad idea?
They have lots of uses:
Sure, I'm aware of the general utility of categories. I was
referring to the specific case where a category is permitted to
override a method. You call it a "misfeature", but Apple don't -
it's still documented, albeit with a number of caveats. Even if they
couldn't remove the functionality for legacy reasons they could
start documenting it in a much more strongly worded fashion to state
that this is simply not permitted. As long as they don't do that,
and as long as the developer is aware of the consequences, I take it
as permitted.
You are correct. The documentation does not fully discuss the risks
inherent therein.
<rdar://problem/6405779> Emphasize the risks of and discourage
developers from categorically overriding methods
Thanks for pointing this out.
Michael Ash pointed wrote
There is. Implement your category method with a different name that
you know will not conflict, for example by adding a prefix. Then at
runtime, check to see if the class already has such a method, and swap
in yours if not.
That still assumes that your method is compatible with the class. A
class may [frequently, as it turns out] have a relatively heavily
optimized implementation internally that relies upon certain state
maintenance and state transitions across its own methods. When
subclassed, the class's method may revert to a behavior that is
designed to support subclassing.
Michael's approach is certainly more defensive and robust, but it will
still potentially cause -- and has -- problems when adding one of the
standard responder methods to a class that didn't implement it
before. Keep in mind that, for NSControl subclasses specifically, a
class can handle events through several different methods, including
manually tracking the event in one of the "raw" methods (like the
mouse tracking methods).
It's simply not safe to override methods in classes you don't control
because you can't ensure that the necessary preconditions are met. By
all means override methods in your own classes, but if you do it to
classes you don't control, you cannot guarantee which one will take
precedence.
Exactly.
b.bum
_______________________________________________
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