hoodwink.d enhanced
RSS
2.0
XHTML
1.0

RedHanded

Category in Objective-C #

by babie in inspect

Translated from matz blog, 2005-03-04

It would seem that the “Category” in Objective-C is near a selector namespace that I worried about since before. Though I can understand the basic concept of selector namespace, I have not been imagined the concrete behavior(and implementation). It is welcome that there is something to refer.

However, I have not understood the specification well in as far as I search by google. Is there a specific example for a concrete behavior and implementation?

Uh-oh, wait.

Anew I read the page I googled, it’s not said that the enable range is static scope. If so, is Category a “Mix-in that cannot be added a instance variable”? It is regrettable when that.

Though there are languages that have selector namespace, for example Smallscript(S#) and JavaScript(ECMAScript 4.0), I have not understood them as of now.

I welcome the information.

said on 06 Mar 2005 at 17:44

Yep, categories are exactly that. Since it’s a C derivative, and ultimately stores instance variables in struct-alikes, there’s no way to add instance variables and maintain binary compatibility, at least in today’s Obj-C runtime. So, while regrettable, it sure is a lot more flexibility than C++ programmers have…

said on 06 Mar 2005 at 21:39

Right. In practice, the Ruby approach, where you can extend a class at any time later, is very similar to the usage of Objective-C categories in practice. In Objective-C, if you need per-instance variables in a category, you can maintain a hash table with pointers to objects. This is tricky to implement, however, because object addresses get reused, and unless you can be notified of the destruction of an object, you may not be able to verify that you have the same object as in a previous invocation of the category methods.

said on 07 Mar 2005 at 14:41

A workaround for this inherent limitation of Objective-C is to use poseAs:. poseAs: might be only available to users of OPENSTEP -derived frameworks or GNUstep, or it may be part of the core Obj-C specification (if such a thing exists). I’m not quite sure :)

Moving on, however, poseAs: allows you to specify a class as a subtitute for an existing one that receives all invocations on that class. You could therefore get the behavior you’re asking as follows:

@interface myPosedClass : someOtherClass {
  id holy,crap,look,at,these,additional;
  id instance,variables;
}
-doSomethingSpecial;
@end
And then, later:
[myPosedClass poseAs:[someOtherClass class]];
someInstance = [[[someOtherClass alloc] init]
   doHorribleThings];

And in that case, the object that is instantiated and receiving the message is actually an instance of myPosedClass

Of course, poseAs: currently has its own limitations, namely that you can not un-pose, or re-pose after it has been done. However, if you’re aiming for true dynamism, you could always pose a class that overrides performSelector: and transparently proxies all messages to other classes; this behavior is easily configurable at runtime.

said on 09 Mar 2005 at 11:14

But adding instance variables will break any subclasses of that class.

Comments are closed for this entry.