Reality Distortion Field Theory
Monday, October 16, 2006
Cocoa:Cocoa Action Categories for Interface Builder (Multiple Inheritance)

So now we've got a fairly general method of doing multiple inheritance within Cocoa applications. Now for some fun stuff. Wouldn't it be great if we could define categories of IB Actions on NSWindow as protocols, and then make it real easy to wire them up using the connection logic of Interface Builder.

As it turns out, this was way easier to do than I thought. Interface Builder is able to read Objective-C header files to find classnames, outlets and actions, but the parser is very easy to fool. All we have to do is wrap our 'action declarations' from our NSWindow category with a preprocessor exclude:

#if 0
/* never compiled, but parsed by IB just fine*/
-(IBAction) dataGoryActionOne:(id)sender;
-(IBAction) dataGoryActionTwo:(id)sender;
-(IBAction) dataGoryActionThree:(id)sender;
/* the great part about actions is their function signature will not be changing!*/

And Interface Builder will parse out the action definitions and allow you to wire connections to them. But the trick is, you don't need to implement the actions - the category methods on NSWindow will take care of that for you.

REMEMBER: if you use this technique of adding actions to NSWindow using a category/protocol, be sure that your ACTION NAMES are VERBOSE, so as to distinguish them from any additions the Cocoa team might make to NSWindow in the future. You have been warned!

Source Code: Cocoa Action Categories.

By : Cocoa Coder Cocoa Action Categories for Interface Builder (Multiple Inheritance) 0 comments

Cocoa:NSWindow(Custom Categories) with instance variables (Multiple Inheritance)

Source Code: Cocoa Bonafide Multiple Inheritance

Here is the code update to my prior post which includes the changes to have a small std::map manage the private instance data.

I've added a third 'case'. I have one IB window which is a custom class derived from NSWindow, another NSPanel derived class, and a third NSWindow instance which is acted on by controller. All three equally adept at responding to methods from NSWindow(DataGory) with private instance data.

Since you're using accessor functions for all your instance data anyway (right!) it doesn't really matter that you can't access the virtual self directly, now does it?

By : Cocoa Coder NSWindow(Custom Categories) with instance variables (Multiple Inheritance) 0 comments

Sunday, October 15, 2006
Cocoa:Categories and Informal Protocols with virtual Instance Variables

Source Code: Cocoa Categories with Instance Data

One thing that I get a kick out of is how the so-called "expert" Cocoa programmers repeat over and over, ad naseum how "Categories" are cool, as long as you understand that you can add methods to existing base classes, but not instance variables.

While this may be true in a strict "syntactical sense", it is certainly not true in the semantic sense. Let's review some principles.

Objective-C categories have as their distant cousins, C++ multiple inheritance, and COM (component object model) aggregation. So if you're familiar with either of those, you will understand them easily.

First of all, an informal protocol is essentially an implementation free declaration of methods around an Objective-C classname.

For example:

/* NSObject_InformalProtocol.h */
@interface NSObject(InformalProtocol)
-(void) informalProtocolMethod;

Categories allow classes which are organized in different places of the class hierarchy to implement groups of methods, or interfaces, which allow behavior to be systematically organized irrespective of position in the inheritance taxonomy.

The problem comes when we want to implement a protocol across some disparate range of objects in the class hierarchy, but to effectively do so, each class which understands the protocol needs some consistent 'private data' or instance variables.

Syntactically, categories define only methods, and as such cannot extend the private data structures of existing classes. However, it is possible to include, among the category methods a method which promises to return instance storage for implementors of the protocol. This basically allows us to defer the allocation of instance variables to some later time, just as we are deferring the implementation of methods to some later time.

I have provided a small, simple example which demonstrates one way this can be done. In the code example, any class adhering to (ie. implementing) the NSWindow(DataGory) is required, by the protocol definition (and enforced by the default implementation) to allocate private storage for the DataGory instance variables. This allows us to organize the 'virtual self' in a typedef, and include it in the exposed definition of NSWindow(DataGory):

/* additional virtual 'instance vars' required by this category */

typedef struct tagNSWindow_DataGory
id goryObject;
void* goryData;
} NSWindow_DataGory;

/* ok, here are the additional methods we are adding to NSWindow */

@interface NSWindow(DataGory)

/* public */

/* protected */

-(NSWindow_DataGory*) get_DataGory_vself; /*implemented by derived classes */


The code example demonstrates adding NSWindow(DataGory) to both a class derived from NSWindow, and another class derived from NSPanel (which inherits from NSWindow). The example itself does nothing. The aim is demonstrate the organizational structure of the technique.

You protest. You say new categories of NSWindow are not useful unless they can be used without requiring the existing NSWindow 'know' anything about the new category. Under these circumstances, a slightly alternate strategy can be used. At least with NSWindow objects.

Basically, to make NSWindow(DataGory) applicable to all instances of classes derived from NSWindow, we alter the method:
-(NSWindow_DataGory*) get_DataGory_vself

Currently, in the code sample, this stub simply performs an NSAssert that always fails and returns a non-crashing set of instance variables. To add NSWindow(DataGory) to all NSWindow instances, we would need some additional static storage, something like a C++ map or a CFMutableDictionary. I'm using map and thus declare:

class class_NSWindow_DataGory : public NSWindow_DataGory
/* initialize members to default values */
#include <map> /* stdc++ template library */

typedef id void_object_id_t;
typedef map<void_object_id_t, class_NSWindow_DataGory > map_objectid_to_DataGory_t;
static map_objectid_to_DataGory_t sMapObjectToDataGory;
-(NSWindow_DataGory*) get_DataGory_vself
NSWindow_DataGory* virtual_self = &sMapObjectToDataGory[self]; /* creates new storage if necessary */
/* register notification of NSWindow deletion/release here */
/* ie. something like
[[NSNotificationCenter defaultCenter]
name: NSWindowWillCloseNotification
object:self ];
where -(void)dataGoryDeleteMe cleans up the mapped storage for itself
return virtual_self;

If you're going to be using categories to add new functionality to classes like NSWindow, I'm warning you now, you better prefix your method and category names with some serious disambiguation text.

Cocoa Source Code: Categories with Virtual Instance Data (Multiple Inheritance technique)

By : Cocoa Coder Categories and Informal Protocols with virtual Instance Variables 1 comments



 [Site Map]    
 Apple News    
 Cocoa Programming    
 Reading List    
 Reality Distortion Field    
 latest apple news iphone    
 latest mac apps news    
 ipad latest news apps    
 iSight Download    
 Best WebCam    
 Screen Capture    

Copyright © 1996-2006
All Rights Reserved
Reality Distortion Field Theory

search this site only.