[Adium-devl] Category instead of protocol

Wed Apr 18 21:20:29 UTC 2007

Hi Evan,
thank you for your details on this.

Well, what I have been told about protocols is, that a class, which  
should conform a protocol, doesn't have to implement the methods from  
the protocol - it can. That depends on the class, which is performing  
conformsToProtocol: (or not) in the end. It also depends on using a  
formal or an informal protocol.
And about categories I've been told that they expand the given class  
about methods, which are useful to habe for the given class. In our  
example this would mean, that every NSObject-class/subclass/instance/ 
whatever should have an implementation of the hasItemDividerBelow:- 
method (referring to my ticket, now) because it is useful.

I think, my problem is just another understanding of protocols and  
categories. I haven't taken a look into the Apple header-files yet,  
but your extract shows me, that you seem to be right here, and  
finally it looks more logical to me.
I'm going to remove the protocol and rewrite the category, so that  
it's according to the rest of Adium (and Apple).

Just to make something clear: I haven't been really active in any  
open-source project yet and if I have done weird code in the past, no- 
one cared about it. My first aim in looking into the code of Adium  
and writing patches and so on, is to learn something from you for   
future projects (Adium, new open-source projects, own projects,  
whatsoever). That also means to ask question about things I've  
learned in books, tutorials and forums.
I know, a developers mailing list is not a newbie-forum and I really  
don't want to annoy anyone, but I think asking a developer for the  
reasons of doing something is more effective than just wondering and  
thinking "Okay, he's doing that like this so I'll do it also in the  
future.". That's the reason why I asked Evan about this (as you can  
see I'm quite doubtful and insecure about that). And if anyone feels  
annoyed or bugged or whatever, please feel free to say that, so I  
know that I should shut up and just listen. ;-)
I just want to make that clear at this point, before someone thinks  
"Shut the f**** up, Christopher" or "What the hell are you doing?". ;-)

Regards,
Christopher

Am 18.04.2007 um 22:48 schrieb Evan Schoenberg:

>
> On Apr 18, 2007, at 9:16 AM, Christopher Harms wrote:
>> I don't want to start a discussion in the ticket system nor the  
>> mailing list (but you can cc: them, if you like), so I'd like to  
>> ask you personally:
>> In ticket #5129 (http://trac.adiumx.com/ticket/5129) you suggested  
>> to create a category for NSObject instead of making a protocol.  
>> Well, I have to admit that I'm not that firm in Objective-C to see  
>> all advantages and disadvantages of the two ways. But this  
>> situation I would prefer a protocol, because I think this is the  
>> most common way, isn't it? And additionally, it doesn't really  
>> make sense for a NSObject to respond the OutlineView-calls (even  
>> if the WindowController-class is a direct or indirect subclass of  
>> NSObject).
>
> I'll cc the list in case this of interest to anyone else.
>
> Protocols are a set of methods which a conforming class must  
> implement in their entirety.  The class should declare that it  
> conforms to the protocol in its interface declaration with <Foo>.
>
> Categories on NSObject should be used to declare the methods which  
> NSObject may respond to; -[NSObject respondsToSelector:] should be  
> used before the actual call to verify the object does respond to it.
>
> If you wanted to have a required set of methods for a delegate, a  
> protocol -- and then requiring that an object conforming to that  
> protocol in setDelegate: -- would be appropriate.  That's very  
> rarely the case, though, and isn't in this one.
>
> All Apple delegate methods of which I'm aware are declared as  
> categories on NSObject. For example, NSOutlineView.h says:
> @interface NSObject(NSOutlineViewDelegate)
> /* NSOutlineView replacements
> */
> - (void)outlineView:(NSOutlineView *)outlineView willDisplayCell: 
> (id)cell forTableColumn:(NSTableColumn *)tableColumn item:(id)item;
> - (BOOL)outlineView:(NSOutlineView *)outlineView  
> shouldEditTableColumn:(NSTableColumn *)tableColumn item:(id)item;
> - (BOOL)selectionShouldChangeInOutlineView:(NSOutlineView *) 
> outlineView;
> - (BOOL)outlineView:(NSOutlineView *)outlineView shouldSelectItem: 
> (id)item;
> - (BOOL)outlineView:(NSOutlineView *)outlineView  
> shouldSelectTableColumn:(NSTableColumn *)tableColumn;
>
> #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_3
> - (void)outlineView:(NSOutlineView *)outlineView  
> mouseDownInHeaderOfTableColumn:(NSTableColumn *)tableColumn;
> - (void)outlineView:(NSOutlineView *)outlineView  
> didClickTableColumn:(NSTableColumn *)tableColumn;
> - (void)outlineView:(NSOutlineView *)outlineView didDragTableColumn: 
> (NSTableColumn *)tableColumn;
> #endif
>
> #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4
> /* tool tip support
>         When the user pauses over a cell, the value returned from  
> this method will be displayed in a tooltip.  'point' represents the  
> current mouse location in view coordinates.  If you don't want a  
> tooltip at that location, return nil or the empty string.  On  
> entry, 'rect' represents the proposed active area of the tooltip.   
> By default, rect is computed as [cell  
> drawingRectForBounds:cellFrame].  To control the default active  
> area, you can modify the 'rect' parameter.
> */
> - (NSString *)outlineView:(NSOutlineView *)ov toolTipForCell: 
> (NSCell *)cell rect:(NSRectPointer)rect tableColumn:(NSTableColumn  
> *)tc item:(id)item mouseLocation:(NSPoint)mouseLocation;
>
> /* Optional - Variable Row Heights
>         Implement this method to support an outline view with  
> varying row heights.  The height returned by this method should not  
> include intercell spacing and must be >0.  Performance  
> Considerations: For large tables in particular, you should make  
> sure that this method is efficient.  NSTableView may cache the  
> values this method returns.  So if you would like to change a row's  
> height make sure to invalidate the row height by calling - 
> noteHeightOfRowsWithIndexesChanged:.  NSTableView automatically  
> invalidates its entire row height cache in -reloadData, and - 
> noteNumberOfRowsChanged.
> */
> - (float)outlineView:(NSOutlineView *)outlineView heightOfRowByItem: 
> (id)item;
> #endif
>
> /* NSOutlineView specific
> */
> - (BOOL)outlineView:(NSOutlineView *)outlineView shouldExpandItem: 
> (id)item;
> - (BOOL)outlineView:(NSOutlineView *)outlineView shouldCollapseItem: 
> (id)item;
> - (void)outlineView:(NSOutlineView *)outlineView  
> willDisplayOutlineCell:(id)cell forTableColumn:(NSTableColumn *) 
> tableColumn item:(id)item;
>
> @end
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070418/75e8f682/attachment-0001.html>