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: "Michael Ash" <email@hidden>
- Date: Thu, 27 Nov 2008 22:50:01 -0500
On Thu, Nov 27, 2008 at 7:24 PM, Graham Cox <email@hidden> wrote:
>
>> Please don't do this! It will apply to every single slider in your
>> process, even ones you didn't create yourself,
>
> Well, that is potentially a "feature". I guess the point would be to test
> your UI thoroughly and make sure it was what you wanted *everywhere*. But if
> that was what you wanted, doing it in a subclass would be more awkward,
> since you might not be able to "get at" every instance in the UI (e.g. the
> opacity slider in NSColorPanel) to set its class, especially now that
> -poseAsClass: is out of bounds.
It's a feature so long as it works properly. The problem is when Apple
makes some change that conflicts with your own. Suddenly you get weird
behavior that's out of your control.
Also, -poseAsClass: is only out of bounds because it's been replaced
by a more general mechanism that's even more powerful. Look up the
method_exchangeImplementations() function for more information.
>> and if at some point
>> Apple adds their own -scrollWheel: implementation, it will end up
>> fighting with yours and it's not guaranteed whose will win.
>
> Yep, that's a potentially more serious issue. It would be nice if a category
> had a way to check for an existing implementation and quietly no-op itself.
> Just checking respondsToSelector: doesn't work of course, always returning
> YES.
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.
> Right now, overriding methods in a category is not only legal, but
> documented as supported. Either Apple should come right out and say this is
> not allowed or rig the runtime to prevent it. As long as it's legal and
> documented as such, the judgement as to whether to add functionality in this
> manner rests with the developer. What's the point of a runtime feature you
> can't ever use?
Overriding methods in a category is supported, yes, and a category
will always win over a method that's implemented directly in a class.
The problem is that you have no guarantee that Apple's hypothetical
future implementation will be directly in a class. They might put it
in a category too. At that point, you have no guarantee who "wins". It
could change from one release to the next, or even from one run to the
next.
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.
Mike
_______________________________________________
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