On Jul 30, 2008, at 12:36 AM, Torsten Curdt wrote:
Even more interesting :) Thanks for sharing that Bill.I've had another idea: Using a protocol would also be a way of shielding the framework from the implementation details. The only problem is that class methods are not allowed in a protocol. And the framework's main entry class currently uses a singleton pattern.
Where does it say that protocols can't include class methods? If there is documentation indicating as much then there is a bug somewhere and I'd like to know about it.
The following works as expected -- the compiler complains mightily about the lack of conformance to protocol Bob in class Fred.
@protocol Bob + (void) foo; @end @interface Fred : NSObject <Bob> @end @implementation Fred @end ---However, protocols are not generally used to hide implementation details. It sounds more like you want a combination of public and private headers / declarations.
For Cocoa, functionality that is supported is made available through public headers. Functionality that is internal to Cocoa is encapsulated in private headers that declare said private interfaces through a combination of categories, class extensions and full-on class declarations.
b.bum
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
