On Nov 28, 2008, at 11:52 AM, Graham Cox wrote:
In which case Apple should a) explicitly document this as a no-no,
and b) disallow categories to install methods that already exist. I
would have thought b) was possible, as when loading a category, I
assume what's really happening is that the method table for the
class is being populated. If the "slot" is already occupied, just
don't install that method.
From the documentation:
...
A category can also override methods declared in the class interface.
However, it cannot reliably override methods declared in another
category of the same class. A category is not a substitute for a
subclass. It’s best if categories don’t attempt to redefine methods
that are explicitly declared in the class’s @interface section.
...
The underlying problem is one of legacy. There is a bunch of code out
there that relies upon replacing existing methods when loading
categories. Removing this particular misfeature will not be without
its pain. Apple goes to great lengths to ensure binary compatibility
between releases.
What use is it, if it's such a bad idea?
They have lots of uses:
- dividing class implementations across multiple files for
organizational purposes
- dividing a class implementation across multiple frameworks with
appropriate layering (See NSAttributedString)
- adding isolated/orthogonal functionality to existing classes,
including universal functionality to NSObject
- making a class modular across different compilation/link units
(Example: I used to split classes apart such that I could have one
version that could render w/o underlying infrastructure in an IB
palette and the real version that relied upon infrastructure for use
in the app. The piece of the view that interfaced to the control/
model layer was contained in a category and could be swapped w/one
that could generate its own data for the purposes of IB.)
b.bum
_______________________________________________
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]
